ما هو ملف .htaccess وكيف تستخدمه بأمان؟

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

ما هو ملف .htaccess بالضبط وكيف يعمل؟

اسم الملف اختصار لعبارة hypertext access، أي «الوصول إلى النص التشعّبي». في الأصل صُمّم ليتيح لمالك موقع على خادم مشترك أن يضبط سلوك الوصول إلى مجلّده دون أن يملك صلاحية تعديل الإعداد الرئيسي للخادم. هذه الفكرة الأصلية هي مفتاح فهم الملف كلّه: هو إعداد لامركزي وموزّع يمنحك سلطة محدودة على مجلّدك وحدك، بينما يبقى ملف الإعداد الرئيسي (httpd.conf أو ملفات الـvhost) حكرًا على مدير الخادم.

عمليًا هو ملف نصّي عادي — لا امتداد له ولا صيغة خاصة — تكتب فيه توجيهات (directives) يفهمها أباتشي، سطرًا في كل مرّة. لا لغة برمجة، لا متغيّرات ولا حلقات، بل أوامر تصريحية مباشرة من نوع: «أعد توجيه هذا المسار إلى ذاك»، «امنع الوصول إلى هذا الملف»، «أضف هذه الترويسة إلى الاستجابة». بساطته هذه هي مصدر قوّته ومصدر خطورته في آنٍ واحد: سطر واحد قد يحوّل موقعك من HTTP إلى HTTPS بالكامل، وسطر آخر خاطئ قد يُسقطه بالكامل.

لماذا يبدأ الاسم بنقطة ولماذا لا تراه؟

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

الحل بسيط: فعّل خيار إظهار الملفات المخفية. في مدير ملفات cPanel تجده عند فتح المدير في نافذة Settings أعلى اليمين، بخيار اسمه Show Hidden Files (dotfiles). إن لم تكن معتادًا على مدير الملفات ومكوّنات اللوحة عمومًا، فـدليل cPanel للمبتدئين يشرح لك أقسامها ومن أين تبدأ. أما في برنامج FileZilla فالخيار في قائمة Server ← Force showing hidden files، وتفاصيل الاتصال والرفع تجدها في شرح رفع الملفات عبر FTP وFileZilla.

كيف يقرأ الخادم الملف في كل طلب؟

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

الأثر مزدوج. الميزة: أي تعديل تكتبه يسري فورًا بلا إعادة تشغيل للخادم، وهذا سبب شعبيته الهائلة في الاستضافة المشتركة. العيب: عمليات قراءة قرص إضافية في كل طلب، وتحليل نصّي متكرّر للقواعد. على موقع بزيارات متواضعة الفارق غير محسوس، لكن على موقع بآلاف الطلبات في الدقيقة، أو حين يمتلئ الملف بمئات قواعد إعادة التوجيه، تبدأ الكلفة بالظهور كملّي ثوانٍ إضافية في زمن الاستجابة الأول (TTFB). القاعدة العملية: إن كنت على خادم تملك جذره، انقل القواعد الثابتة إلى إعداد الـvhost حيث تُقرأ مرّة واحدة عند التشغيل، وأبقِ .htaccess للحالات التي تحتاج فيها تعديلًا سريعًا.

الوراثة: ملف لكل مجلّد

يمكن أن يوجد أكثر من ملف .htaccess في موقع واحد، واحد في كل مجلّد. الملف في مجلّد فرعي يرث توجيهات الملف الأعلى منه، ويستطيع أن يضيف عليها أو يتجاوز بعضها. هذه الوراثة مفيدة جدًا: تضع القواعد العامة في ملف الجذر داخل public_html، ثم تضع قاعدة أمنية ضيّقة داخل wp-content/uploads مثلًا تمنع تنفيذ PHP هناك وحدها، دون أن تؤثّر على بقية الموقع.

لكن الوراثة أيضًا مصدر خفيّ للحيرة. إن كتبت قاعدة في الجذر وبدت وكأنها «لا تعمل» في مجلّد معيّن، فغالبًا هناك ملف .htaccess آخر داخل ذلك المجلّد يتجاوزها. وبعض إضافات ووردبريس والأدوات الأمنية تنشئ ملفات .htaccess فرعية بصمت في مجلّدات مثل wp-content أو wp-admin. قبل أن تشكّ في قاعدتك، ابحث في شجرة المجلّدات كلها عن ملفات .htaccess أخرى.

أين يوجد الملف وكيف تصل إليه؟

الملف الأهمّ يعيش في جذر موقعك المنشور، أي داخل public_html (أو www أو htdocs حسب المضيف). هذا هو الملف الذي يؤثّر على الموقع كله. إن كان لديك نطاق فرعي أو نطاق إضافي، فلكل واحد جذره الخاص وملفه الخاص. أما مجلّد الحساب الرئيسي (Home) الذي يقع فوق public_html فلا يُقرأ منه شيء لأنه خارج مسار النشر.

ماذا لو لم يكن الملف موجودًا أصلًا؟

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

انتبه لفخّ ويندوز: مستكشف الملفات يرفض في أحوال كثيرة إنشاء ملف اسمه يبدأ بنقطة، وبعض المحرّرات تضيف امتداد .txt بصمت فيصبح الاسم .htaccess.txt ولا يقرأه الخادم إطلاقًا. اكتب الملف في محرّر نصّي حقيقي (VS Code أو Notepad++)، واحفظه بترميز UTF-8 بلا BOM وبنهايات أسطر LF لا CRLF. علامة BOM غير المرئية في بداية الملف كفيلة وحدها بإسقاط الموقع بخطأ 500 دون سبب ظاهر.

أذونات الملف الصحيحة

الإذن المناسب لملف .htaccess هو 644 (قراءة وكتابة للمالك، قراءة فقط للبقية). لا تضبطه على 777 مهما نصحك أحد بذلك لحلّ مشكلة صلاحيات، فهذا يعني أن أي عملية على الخادم تستطيع الكتابة فيه — وملف يتحكّم في التوجيه والحماية بيد مهاجم يعني موقعًا مسروقًا بالكامل. بعض الخوادم المشدّدة ترفض قراءة ملف بإذن 777 وتردّ بخطأ 500، وهي في الحقيقة تحميك.

أباتشي وLiteSpeed مقابل Nginx — النقطة التي يخطئ فيها الجميع

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

لذلك إن رفعت ملف .htaccess على خادم Nginx، لن يحدث شيء على الإطلاق: لا خطأ، لا تحذير، ولا تأثير. الملف يبقى موجودًا بصمت كملف نصّي عادي (بل قد يكون قابلًا للتنزيل من المتصفّح إن لم تمنعه). البديل الصحيح على Nginx هو كتابة التوجيهات داخل كتلة server في ملف إعداد الموقع، ثم إعادة تحميل الخدمة — وهذا يتطلّب صلاحية جذر على الخادم، أي يخصّ VPS والخوادم المخصّصة، أو يُطلب من مدير الخادم أو الدعم الفني على الاستضافة المُدارة.

أما LiteSpeed وOpenLiteSpeed فيقرآن .htaccess بتوافق عالٍ جدًا مع أباتشي، وهذا سبب رئيسي لانتشارهما في الاستضافة المشتركة: يعطيان أداء قريبًا من Nginx مع إبقاء مرونة .htaccess بيد العميل. للتوسّع في الفروق المعمارية وأيّهما يناسب حالتك، راجع المقارنة بين LiteSpeed وNginx.

القاعدة الذهبية: نسخة احتياطية قبل أي تعديل

هذه ليست نصيحة روتينية تُقال في كل دليل، بل شرط عملي لا تفاوض عليه. ملف .htaccess من الحالات النادرة التي يكون فيها خطأ إملائي واحد كافيًا لإسقاط الموقع كلّه في اللحظة نفسها، لأن التعديل يسري فورًا ولا توجد مرحلة «تجميع» أو «تحقّق» تلتقط الخطأ قبل النشر. حرف زائد في اسم توجيه، وسم IfModule لم تغلقه، أو اقتباس ناقص — والنتيجة صفحة بيضاء تحمل 500 Internal Server Error لكل زائر، بما فيهم أنت، وبما في ذلك لوحة تحكّم ووردبريس التي كنت ستستخدمها للإصلاح.

كيف تأخذ نسخة في ثلاثين ثانية

قبل أن تلمس الملف، انسخه باسم آخر في المجلّد نفسه: htaccess-backup-2026-07-28 مثلًا. لاحظ أننا حذفنا النقطة من بداية الاسم عمدًا — فبهذا يتوقّف الخادم عن اعتباره ملف إعداد ويصبح مجرّد ملف نصّي خامل. لو ساءت الأمور، احذف الملف المعطوب وأعد تسمية النسخة إلى .htaccess وعاد الموقع في ثوانٍ.

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

عدّل قاعدة واحدة ثم اختبر

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

جاهز لإطلاق موقعك على استضافة سريعة؟

خطط استضافة wpressly على أقراص NVMe مع SSL مجاني ودعم عربي — اختر الخطة المناسبة لحجمك وانطلق اليوم.

اكتشف خطط الاستضافة

بنية الملف وترتيب القواعد

الملف يُقرأ من أعلى إلى أسفل، والترتيب يهمّ فعلًا. القاعدة الأولى التي تطابق الطلب تُنفَّذ، وقد يتوقّف التنفيذ عندها إن حملت العَلَم [L] (اختصار Last). لهذا ضع القواعد الأضيق والأكثر تحديدًا في الأعلى، والقواعد العامة الشاملة في الأسفل. ولو عكست الترتيب فوضعت قاعدة عامة تطابق كل شيء في البداية، فلن تصل القواعد التالية إلى دورها أبدًا.

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

# ————— قواعدي الخاصة (خارج كتلة ووردبريس) —————

# 1) تعطيل فهرسة محتويات المجلّدات
Options -Indexes

# 2) تحديد الملف الافتراضي عند طلب مجلّد
DirectoryIndex index.php index.html

# 3) الترميز الافتراضي للملفات النصّية
AddDefaultCharset UTF-8

شرح سطرًا سطرًا: Options -Indexes يمنع أباتشي من عرض قائمة بالملفات حين لا يجد ملفًا افتراضيًا في المجلّد — لولاه لتمكّن أي زائر من تصفّح محتويات wp-content/uploads أو مجلّد النسخ الاحتياطي ورؤية ما بداخله. DirectoryIndex يحدّد بأي ترتيب يبحث الخادم عن الملف الافتراضي، فيجرّب index.php أوّلًا ثم index.html. وAddDefaultCharset UTF-8 يضمن أن يعلن الخادم الترميز الصحيح في ترويسة الاستجابة، وهو ما يمنع ظهور النصوص العربية كرموز مشوّهة في الصفحات الثابتة.

إعادة التوجيه 301 و302 — الاستخدام الأكثر شيوعًا

إعادة التوجيه هي أن يطلب الزائر عنوانًا فيردّ عليه الخادم قائلًا: «هذا العنوان لم يعد هنا، اذهب إلى ذاك». الفرق بين رموزها ليس تفصيلًا تقنيًا بل قرار له أثر مباشر على أرشفة موقعك: الرمز 301 يخبر محرّكات البحث أن النقل دائم، فتحوّل قيمة الصفحة القديمة وروابطها الخلفية إلى الجديدة وتستبدل العنوان في الفهرس. أما 302 فيقول «مؤقّت»، فتبقي المحرّكات العنوان القديم في الفهرس ولا تنقل شيئًا. استخدام 302 في نقل دائم من أشيع أخطاء الهجرات، ونتيجته خسارة ترتيب كان يمكن الحفاظ عليه بالكامل.

لفهم أوسع لبقية رموز الحالة ومعانيها، راجع صفحة رموز حالة HTTP في الويكي.

الطريقة الأولى: توجيه Redirect البسيط

# توجيه صفحة واحدة إلى أخرى — دائم
Redirect 301 /old-page.html /new-page.html

# توجيه صفحة إلى موقع خارجي
Redirect 301 /partner https://example.com/landing

# إعلان صفحة محذوفة نهائيًا بلا بديل
Redirect 410 /discontinued-product

Redirect أبسط أداة وتكفي للحالات الفردية. الصيغة: الكلمة، ثم رمز الحالة، ثم المسار القديم مبدوءًا بشرطة مائلة، ثم الوجهة. لاحظ أن سطر الـ410 لا يأخذ وجهة إطلاقًا — فالمعنى «حُذف ولا بديل»، وإضافة وجهة له خطأ صياغة يُسقط الموقع.

الطريقة الثانية: RedirectMatch للأنماط

# نقل مجلّد كامل مع الحفاظ على المسار الداخلي
RedirectMatch 301 ^/blog/(.*)$ /articles/$1

# توحيد الروابط المنتهية بامتداد .html
RedirectMatch 301 ^/(.*)\.html$ /$1

هنا نستخدم التعابير النمطية. الرمز ^ يعني بداية المسار، (.*) يلتقط كل ما يليه، و$1 يعيد استخدام ما التُقط في الوجهة. القاعدة الأولى تحوّل /blog/my-post إلى /articles/my-post تلقائيًا لكل مقالات المدوّنة دفعة واحدة، بدل كتابة سطر لكل مقال. هذه القاعدة وحدها توفّر عليك مئات الأسطر عند إعادة هيكلة موقع.

الطريقة الثالثة: RewriteRule حين تحتاج شروطًا

<IfModule mod_rewrite.c>
  RewriteEngine On

  # وجّه فقط الزوّار القادمين من نطاق معيّن
  RewriteCond %{HTTP_REFERER} old-domain\.com [NC]
  RewriteRule ^(.*)$ https://example.com/welcome [R=301,L]

  # اجعل صفحة محذوفة تردّ 410 بدل 404
  RewriteRule ^old-section/?$ - [G,L]
</IfModule>

RewriteCond شرط يُختبر قبل القاعدة التي تليه مباشرة، والقاعدة لا تُنفَّذ إلا إن تحقّق. الأعلام بين القوسين: R=301 يعني «أعد التوجيه بهذا الرمز»، L يعني «توقّف هنا ولا تكمل القواعد التالية»، NC يعني «تجاهل حالة الأحرف»، وG يعني «ردّ بـ410 Gone». الشرطة - في موضع الوجهة تعني «لا تغيّر المسار، فقط طبّق العَلَم».

فرض HTTPS وتوحيد نسخة www

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

<IfModule mod_rewrite.c>
  RewriteEngine On

  # 1) فرض HTTPS على كل الطلبات
  RewriteCond %{HTTPS} !=on
  RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]

  # 2) توحيد الموقع على النسخة بلا www
  RewriteCond %{HTTP_HOST} ^www\.(.+)$ [NC]
  RewriteRule ^ https://%1%{REQUEST_URI} [R=301,L]
</IfModule>

الكتلة الأولى: %{HTTPS} !=on يعني «إن لم يكن الاتصال مشفّرًا»، فنعيد بناء العنوان نفسه بادئًا بـhttps:// مع %{HTTP_HOST} (النطاق كما طلبه الزائر) و%{REQUEST_URI} (المسار الكامل بعد النطاق). النتيجة: زائر يفتح http://example.com/blog/post ينتقل إلى https://example.com/blog/post مباشرة لا إلى الصفحة الرئيسية — وهذه نقطة حاسمة يخطئ فيها كثير من الأكواد المتداولة.

الكتلة الثانية توحّد على النسخة بلا www: الشرط يلتقط ما بعد www. في متغيّر يُشار إليه بـ%1، ثم نعيد البناء بدونه. لو أردت العكس — أي التوحيد على www — استبدلها بهذه:

  # توحيد على النسخة بـ www (بديل عن الكتلة الثانية أعلاه)
  RewriteCond %{HTTP_HOST} !^www\. [NC]
  RewriteCond %{HTTP_HOST} !^localhost [NC]
  RewriteRule ^ https://www.%{HTTP_HOST}%{REQUEST_URI} [R=301,L]

حلقة التوجيه خلف CDN أو بروكسي

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

<IfModule mod_rewrite.c>
  RewriteEngine On
  RewriteCond %{HTTPS} !=on
  RewriteCond %{HTTP:X-Forwarded-Proto} !https
  RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]
</IfModule>

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

إضافة HSTS

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

<IfModule mod_headers.c>
  Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains"
</IfModule>

الكلمة always تضمن إرسال الترويسة حتى مع استجابات الخطأ، وmax-age بالثواني (هنا سنة كاملة). كن حذرًا مع includeSubDomains: هي تشمل كل نطاقاتك الفرعية، فإن كان أحدها بلا شهادة سيصبح غير قابل للوصول. ابدأ بمدّة قصيرة للاختبار، وراجع شرح HSTS في الويكي قبل التثبيت النهائي. ولبقية ترويسات الأمان — سياسة المحتوى ومنع التأطير وغيرها — التفصيل الكامل في دليل ترويسات أمان HTTP.

الروابط الدائمة في ووردبريس

حين تفتح الإعدادات ← الروابط الدائمة وتختار بنية مثل «اسم المقالة»، فما يحدث خلف الستار أن ووردبريس يكتب كتلة في .htaccess تقول للخادم: «إن طلب أحد مسارًا لا يقابله ملف موجود ولا مجلّد موجود، فمرّره إلى index.php ودعه يتولّى الأمر». بلا هذه الكتلة تعمل الصفحة الرئيسية بشكل طبيعي بينما ترد كل المقالات بخطأ 404 — وهو عرَض شهير يربك المبتدئين بعد نقل موقع.

# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# END WordPress

الشرطان !-f و!-d هما جوهر الفكرة: -f يعني «ملف موجود» و-d يعني «مجلّد موجود»، وعلامة التعجّب تنفيهما. أي أن التمرير إلى index.php لا يحدث إلا للمسارات التي لا تقابل شيئًا حقيقيًا على القرص — وهكذا تبقى الصور وملفات CSS تُقدَّم مباشرة بلا مرور على PHP. أما سطر E=HTTP_AUTHORIZATION فيمرّر ترويسة المصادقة إلى PHP، وهو ضروري لعمل واجهة REST المصادَق عليها على بعض الخوادم.

إن واجهت مشكلات في ووردبريس بعد التعديل — 404 على كل الصفحات، أو شاشة بيضاء، أو لوحة لا تُفتح — ففي دليل حلّ أخطاء ووردبريس الشائعة تسلسل تشخيصي كامل يبدأ من .htaccess نفسه لأنه المشتبه به الأوّل في أغلب هذه الحالات.

حماية الملفات الحسّاسة

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

# منع الوصول إلى الملفات الحسّاسة
<Files "wp-config.php">
  Require all denied
</Files>

<Files "xmlrpc.php">
  Require all denied
</Files>

# منع تنزيل ملفات السجلّات والنسخ وقواعد البيانات
<FilesMatch "(?i)\.(log|sql|bak|old|swp|ini)$">
  Require all denied
</FilesMatch>

# تعطيل فهرسة محتويات المجلّدات
Options -Indexes

Files يطابق اسم ملف محدّدًا، وFilesMatch يطابق نمطًا بتعبير نمطي. البادئة (?i) تجعل المطابقة غير حسّاسة لحالة الأحرف، فيُحجب backup.SQL كما يُحجب backup.sql. وعبارة Require all denied هي صيغة أباتشي 2.4 الحديثة لمنع الوصول من الجميع.

وهذه الكتلة تُوضع في ملف .htaccess داخل مجلّد wp-content/uploads تحديدًا، لا في الجذر — وهي من أعلى إجراءات الحماية عائدًا في ووردبريس، لأن أغلب الاختراقات تنتهي برفع ملف PHP خبيث إلى مجلّد المرفوعات ثم استدعائه:

# ضعه في: wp-content/uploads/.htaccess
<FilesMatch "(?i)\.(php|phtml|php[0-9]|phps|pht)$">
  Require all denied
</FilesMatch>

حظر عناوين IP والتحكّم في الوصول

# حظر عناوين محدّدة مع السماح للبقية
<RequireAll>
  Require all granted
  Require not ip 203.0.113.45
  Require not ip 198.51.100.0/24
</RequireAll>

RequireAll تعني «يجب أن تتحقّق كل الشروط بالداخل»: السماح العام متحقّق للجميع، لكن شرط «ليس هذا العنوان» يفشل للعناوين المذكورة فتُحجب. تستطيع كتابة عنوان مفرد أو نطاقًا كاملًا بصيغة CIDR كما في السطر الأخير الذي يحجب 256 عنوانًا دفعة واحدة، وهي صيغة عملية لحجب مصدر إزعاج متكرّر يأتي من شبكة واحدة.

والعكس مفيد أكثر: قصر صفحة الدخول على عنوانك أنت وحدك، وهو إجراء يُنهي هجمات تخمين كلمة المرور من جذرها إن كان لديك عنوان ثابت:

# السماح لعنوانك وحده بفتح صفحة الدخول
<Files "wp-login.php">
  Require ip 203.0.113.45
</Files>

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

موقع آمن يبدأ من استضافة آمنة

استضافة wpressly تأتيك بـSSL مجاني وحماية مدمجة ونسخ احتياطي تلقائي — أمّن موقعك وزوّارك من اليوم الأول.

اكتشف الاستضافة الآمنة

منع سرقة الصور (Hotlinking)

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

<IfModule mod_rewrite.c>
  RewriteEngine On

  # اسمح بالطلبات المباشرة (بلا مُحيل)
  RewriteCond %{HTTP_REFERER} !^$

  # اسمح لنطاقك أنت
  RewriteCond %{HTTP_REFERER} !^https?://(www\.)?example\.com [NC]

  # اسمح لمحرّكات البحث ومنصّات المعاينة
  RewriteCond %{HTTP_REFERER} !google\. [NC]
  RewriteCond %{HTTP_REFERER} !bing\. [NC]

  # امنع بقيّة المواقع من تحميل الصور
  RewriteRule \.(jpe?g|png|gif|webp|avif|svg)$ - [F,NC]
</IfModule>

المنطق تراكمي: كل RewriteCond استثناء يُضاف، والقاعدة الأخيرة لا تُنفَّذ إلا إن سقطت كل الاستثناءات. الشرط الأول !^$ مهم جدًا لأنه يسمح بالطلبات التي لا تحمل مُحيلًا إطلاقًا — وهذا ما يحدث حين يفتح المستخدم رابط الصورة مباشرة، أو حين يخفي متصفّحه المُحيل لأسباب خصوصية؛ بدونه ستحجب مستخدمين شرعيين. والعَلَم F يعني Forbidden أي ردّ بخطأ 403. استبدل example.com بنطاقك، ولا تنسَ إضافة نطاق شبكة التوصيل إن كنت تستخدم واحدة، وإلا ستحجب صورك عن نفسك.

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

الضغط والتخزين المؤقّت في المتصفّح

هذان الاستخدامان من أسرع مكاسب الأداء التي يمكن أن تحصل عليها بسطور قليلة، لأنهما يقلّلان حجم ما يُنقل وعدد ما يُطلب أصلًا في الزيارات التالية.

ضغط النصوص عبر mod_deflate

<IfModule mod_deflate.c>
  AddOutputFilterByType DEFLATE text/html text/plain text/xml text/css
  AddOutputFilterByType DEFLATE application/javascript application/json
  AddOutputFilterByType DEFLATE application/xml image/svg+xml
  AddOutputFilterByType DEFLATE font/ttf font/otf
</IfModule>

كل سطر يضيف أنواع محتوى تُضغط قبل إرسالها ثم يفكّها المتصفّح تلقائيًا. المكسب على ملفات HTML وCSS وJavaScript ضخم — تقليص يتراوح غالبًا بين 60% و80% من الحجم — لأنها نصوص متكرّرة الأنماط. لاحظ ما لم نضعه في القائمة: الصور بصيغ JPEG وPNG وWebP، وملفات الفيديو، وخطوط WOFF2. هذه مضغوطة أصلًا بخوارزمياتها الخاصة، وإعادة ضغطها تستهلك معالجًا بلا مكسب يُذكر وقد تزيد الحجم قليلًا. للتفصيل في خوارزميات الضغط والفرق بينها راجع شرح Gzip وBrotli في الويكي.

التخزين المؤقّت عبر mod_expires

<IfModule mod_expires.c>
  ExpiresActive On
  ExpiresDefault "access plus 1 month"

  ExpiresByType text/html "access plus 0 seconds"
  ExpiresByType text/css "access plus 1 year"
  ExpiresByType application/javascript "access plus 1 year"
  ExpiresByType image/webp "access plus 1 year"
  ExpiresByType image/avif "access plus 1 year"
  ExpiresByType image/jpeg "access plus 1 year"
  ExpiresByType font/woff2 "access plus 1 year"
</IfModule>

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

المدّة الطويلة آمنة بشرط أن تحمل ملفاتك بصمة في أسمائها تتغيّر مع كل نسخة (مثل style.a3f9c1.css)، وهو ما تفعله أدوات البناء وإضافات الكاش الحديثة تلقائيًا. بدون هذه البصمة ستضطرّ لانتظار انتهاء المدّة قبل أن يرى الزوّار تعديلاتك. ويمكن ضبط السلوك نفسه بترويسة Cache-Control الأدقّ:

<IfModule mod_headers.c>
  <FilesMatch "(?i)\.(css|js|woff2|webp|avif|png|jpe?g|svg)$">
    Header set Cache-Control "public, max-age=31536000, immutable"
  </FilesMatch>
</IfModule>

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

صفحات الخطأ المخصّصة

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

ErrorDocument 400 /errors/400.html
ErrorDocument 401 /errors/401.html
ErrorDocument 403 /errors/403.html
ErrorDocument 404 /errors/404.html
ErrorDocument 500 /errors/500.html

استخدم مسارًا نسبيًا يبدأ بشرطة مائلة كما في المثال. لو كتبت عنوانًا كاملًا يبدأ بـhttps:// سيصدر أباتشي إعادة توجيه 302 بدل عرض الصفحة، فيفقد الطلب رمز الخطأ الأصلي — ونتيجته أن محرّكات البحث ترى «صفحة موجودة» حيث يجب أن ترى 404، وهي حالة الـsoft 404 الضارّة بالأرشفة. وانتبه إلى ألا تكون صفحات الخطأ نفسها محجوبة أو داخل مجلّد يتطلّب مصادقة، وإلا دخلت في مسار خطأ متداخل.

استكشاف الأخطاء وإصلاحها

أولًا: خطأ 500 بعد التعديل مباشرة

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

أعد تسمية الملف إلى htaccess-broken من مدير الملفات وحدّث الموقع. إن عاد يعمل، فقد أكّدت المصدر ولم يعد التشخيص تخمينًا. افتح النسخة المعطوبة وراجع آخر كتلة أضفتها: هل أغلقت كل وسم IfModule أو Files فتحته؟ هل كل اقتباس مزدوج له نظير يغلقه؟ هل الوحدة التي تستدعيها مثبّتة أصلًا؟ ثم أعد الكتلة سطرًا سطرًا حتى يظهر الخطأ فتعرف السطر بعينه.

للتأكيد النهائي اقرأ سجلّ أخطاء الخادم — في cPanel من قسم Metrics ← Errors، أو ملف error_log في مجلّد موقعك. السجلّ عادة يعطيك السطر بالرقم ورسالة صريحة مثل Invalid command 'Header' التي تعني ببساطة أن mod_headers غير مثبّت وأن الحل هو لفّ الكتلة داخل IfModule.

ثانيًا: حلقة إعادة توجيه لا نهائية

يظهر المتصفّح رسالة ERR_TOO_MANY_REDIRECTS أو ما يشابهها، ولا يُفتح الموقع إطلاقًا. الأسباب الأربعة الأكثر شيوعًا: قاعدتان متعارضتان لـwww (واحدة تضيفه وأخرى تحذفه)؛ فرض HTTPS خلف بروكسي ينهي التشفير عنده كما شرحنا في القسم السابق؛ إعدادات عنوان الموقع في ووردبريس تشير إلى http:// بينما .htaccess يفرض https:// فيتقاذفان الطلب؛ أو قاعدة توجيه يقع مصدرها ووجهتها في المسار نفسه.

العلاج تشخيصي: عطّل كل قواعد التوجيه بوضع # في بداية أسطرها، وتأكّد أن الموقع يُفتح. ثم فعّل قاعدة واحدة فقط واختبر، وهكذا حتى تظهر الحلقة فتعرف الفاعل. وامسح كاش المتصفّح أو اختبر في نافذة خاصة بين كل محاولة، فالمتصفّح يحتفظ بتوجيهات 301 السابقة ويطبّقها قبل أن يسأل الخادم أصلًا.

ثالثًا: الملف لا يعمل إطلاقًا

كتبت قاعدة، حفظت، ولا شيء يحدث: لا خطأ ولا تأثير. الاحتمالات مرتّبة من الأرجح إلى الأقلّ:

الخادم ليس أباتشي. إن كان Nginx فالملف يُتجاهل تمامًا كما شرحنا. تحقّق من ترويسة Server أوّلًا قبل أي شيء آخر.

التوجيه AllowOverride معطّل. مدير الخادم يستطيع أن يمنع قراءة ملفات .htaccess كلّيًا بضبط AllowOverride None في إعداد الموقع، وهو إجراء أداء شائع على الخوادم المُدارة. في هذه الحالة لا يظهر أي خطأ — الملف يُتجاهل بصمت. لو كنت على خادم تملكه اضبطها على AllowOverride All؛ ولو كنت على استضافة مشتركة راسل الدعم.

اسم الملف أو موقعه خاطئ. تأكّد أنه .htaccess بالضبط بالنقطة الأولى، بلا امتداد مخفي، وأنه داخل الجذر الصحيح للنطاق الذي تختبره لا في مجلّد الحساب الأعلى.

ملف آخر يتجاوز قاعدتك. ابحث عن ملفات .htaccess في المجلّدات الفرعية، وابحث داخل الملف نفسه عن قاعدة أعلى تحمل العَلَم [L] وتطابق الطلب قبل أن تصل قاعدتك إلى دورها.

طبقة كاش تسبق الخادم. إن كانت أمامك شبكة توصيل محتوى أو إضافة كاش تولّد صفحات ثابتة، فقد تُقدَّم الاستجابة من الكاش دون أن يصل الطلب إلى .htaccess أصلًا. امسح الكاش من كل الطبقات ثم أعد الاختبار.

رابعًا: 403 على الموقع كله بعد إضافة قاعدة حماية

يحدث غالبًا حين تكتب Require all denied خارج كتلة Files أو FilesMatch، فتصبح القاعدة سارية على المجلّد كله لا على ملف بعينه. راجع أن كل قاعدة منع محاطة بكتلة تحدّد نطاقها. سبب آخر: قاعدة Require ip بعنوان لم يعد عنوانك بعد أن غيّره مزوّد الإنترنت.

متى لا تستخدم .htaccess؟

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

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

جاهز لإطلاق موقعك على استضافة سريعة؟

خطط استضافة wpressly على أقراص NVMe مع SSL مجاني ودعم عربي — اختر الخطة المناسبة لحجمك وانطلق اليوم.

اكتشف خطط الاستضافة

الأسئلة الشائعة

هل يعمل ملف .htaccess على استضافة Nginx؟ لا، إطلاقًا. Nginx لا يقرأ ملف .htaccess ولا يوجد فيه ما يعادله، وهذا قرار تصميمي متعمّد: كل إعداده يُحمَّل مرّة واحدة عند التشغيل ويبقى في الذاكرة، وهو جزء من سبب سرعته. لو رفعت الملف على خادم Nginx فلن يحدث شيء — لا خطأ ولا تأثير. البديل كتابة التوجيهات داخل كتلة server في ملف إعداد الموقع ثم إعادة تحميل الخدمة، وهذا يحتاج صلاحية جذر. أما LiteSpeed فيقرأ الملف بتوافق عالٍ مع أباتشي، ولهذا تجده منتشرًا في الاستضافة المشتركة.

لماذا لا أرى ملف .htaccess في مدير الملفات؟ لسببين محتملين. الأول والأرجح أن الملف مخفي لأن اسمه يبدأ بنقطة، وعليك تفعيل خيار إظهار الملفات المخفية: في cPanel من نافذة Settings أعلى مدير الملفات بخيار Show Hidden Files، وفي FileZilla من قائمة Server ← Force showing hidden files. الثاني أن الملف غير موجود فعلًا، وهذا طبيعي تمامًا لأنه ليس شرطًا لعمل الموقع. أنشئه بنفسك من زر File + واكتب الاسم .htaccess بالنقطة بالضبط وبلا امتداد.

لماذا ظهر خطأ 500 بعد تعديل الملف وكيف أصلحه فورًا؟ لأن أباتشي يقرأ الملف في كل طلب ويطبّقه فورًا بلا مرحلة تحقّق، فأي خطأ صياغة يوقف الخادم عن معالجة الطلب كله. الإصلاح العاجل: أعد تسمية الملف إلى htaccess-broken من مدير الملفات، وسيعود الموقع خلال ثوانٍ. ثم افتح الملف وراجع آخر كتلة أضفتها — وسم لم يُغلق، اقتباس ناقص، أو توجيه لوحدة غير مثبّتة على الخادم. اقرأ error_log لمعرفة رقم السطر بالضبط، وأعد الكتل واحدة واحدة مع اختبار بعد كل واحدة.

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

هل يبطئ ملف .htaccess موقعي فعلًا؟ نعم، لكن بمقدار يعتمد على حجمه وحجم زياراتك. أباتشي يبحث عن الملف ويقرأه في كل طلب ماشيًا على سلسلة المجلّدات من الجذر إلى المجلّد المطلوب، ولا يخزّنه في الذاكرة مثل إعداد الخادم. على موقع عادي بملف من عشرات الأسطر الأثر غير محسوس. لكن مع مئات قواعد التوجيه أو آلاف الطلبات في الدقيقة يظهر الأثر في زمن الاستجابة الأول. إن ملكت وصولًا إداريًا للخادم، انقل القواعد المستقرّة إلى إعداد الـvhost حيث تُقرأ مرّة واحدة عند التشغيل.

هل أستطيع الكتابة داخل كتلة BEGIN WordPress؟ تقنيًا نعم، لكن لا تفعل. ووردبريس يعتبر ما بين # BEGIN WordPress و# END WordPress ملكًا له ويعيد توليد الكتلة كاملة عند كل حفظ لإعدادات الروابط الدائمة وأحيانًا عند التحديثات، فيُمحى ما كتبته دون إنذار وستحتار في سبب اختفاء قاعدتك. اكتب قواعدك الخاصة فوق سطر البداية أو تحت سطر النهاية. المبدأ نفسه ينطبق على الكتل التي تنشئها إضافات الكاش والأمان — احترم حدود كل كتلة معلّمة بتعليقات مماثلة.

كيف أمنع الوصول إلى ملف wp-config.php؟ بكتلة Files في ملف .htaccess الموجود في جذر الموقع تحوي Require all denied، وهي صيغة أباتشي 2.4 لمنع الوصول من الجميع. الملف يبقى قابلًا للقراءة من PHP نفسه فيعمل موقعك بشكل طبيعي، لكن لا يستطيع أحد فتحه من المتصفّح. أضف إليه حجب xmlrpc.php إن لم تكن تستخدمه، وحجب ملفات .log و.sql و.bak بامتدادها عبر FilesMatch، ومنع تنفيذ PHP داخل wp-content/uploads بملف .htaccess منفصل في ذلك المجلّد تحديدًا.

هل يكفي .htaccess وحده لحماية موقعي؟ لا. .htaccess طبقة واحدة ضمن منظومة، وهو ممتاز في حجب المسارات وحظر العناوين ومنع تنفيذ الملفات في مجلّدات محدّدة — لكنه لا يفحص محتوى الطلبات ولا يكشف البرمجيات الخبيثة ولا يحمي من ثغرة في إضافة قديمة. اجمعه مع تحديثات منتظمة للنظام والإضافات، وكلمات مرور قوية ومصادقة ثنائية، وأذونات ملفات صحيحة (644 للملفات و755 للمجلّدات)، وجدار حماية تطبيقات ويب، ونسخ احتياطي دوري خارج الخادم. الأمان طبقات متراكمة لا إجراء واحد.

المصادر

• توثيق ووردبريس — ملف ‎.htaccess
• ووردبريس — الإعداد على خادم Nginx