مخاطر استخدام .htaccess مع إعادة توجيه 301 أثناء نقل الدومين

من يبحث عن .htaccess 301 redirect يكون عادةً أمام مشكلة مباشرة:

• URL قديم يجب أن ينتقل إلى URL جديد
• HTTP يجب أن يتحول إلى HTTPS
• دومين قديم يجب أن ينتقل بشكل دائم

ولبضع قواعد بسيطة قد تكون .htaccess كافية فعلًا. المشكلة تبدأ عندما تتمدد هذه العادة لتغطي مشروع نقل دومين كامل.

الجواب العملي غالبًا هو:

• مع عدد صغير من تحويلات 301 المستقرة قد تكفي .htaccess
• مع نقل دومين، rebrand، relaunch أو خريطة تحويلات كبيرة تتحول .htaccess بسرعة إلى مصدر خطر تشغيلي

إذا كانت عملية النقل جارية بالفعل، فاحتفظ أيضًا بـ قائمة فحص نقل الموقع مع التحويلات. هذه الصفحة تركز فقط على نقطة دخول شائعة: تحويلات 301 داخل .htaccess.

الشكل الأساسي

لتحويل دائم لصفحة واحدة، قد ترى شيئًا مثل:

Redirect 301 /old-page https://www.example.com/new-page

أما نقل الدومين كاملًا مع الحفاظ على path فيلجأ كثيرون إلى mod_rewrite:

RewriteEngine On
 
RewriteCond %{HTTP_HOST} ^old-domain\.com$ [OR]
RewriteCond %{HTTP_HOST} ^www\.old-domain\.com$
RewriteRule ^(.*)$ https://www.new-domain.com/$1 [R=301,L]

لكن هذا يجيب عن الصياغة فقط. السؤال الأهم هو:

[!TIP] هل ما زلت تدير بضع قواعد فقط، أم أنك صرت تدير workflow نقل يحتاج إلى validation وownership وrollback؟

متى تظل .htaccess مقبولة؟

عادةً تبقى منطقية عندما:

• عدد القواعد قليل
• Apache هي طبقة التحويل الوحيدة
• لا يوجد CDN أو proxy أو middleware يعيد كتابة المسار أيضًا
• منطق الـ path بسيط
• ownership واضح

أين تبدأ المشاكل؟

1. وجود أكثر من طبقة تحويل

في المشاريع الحقيقية قد تأتي القواعد من:

• .htaccess
• إضافات CMS
• Nginx أو load balancer
• Cloudflare
• middleware داخل التطبيق

فتصبح الهجرة كالتالي:

http://old-domain.com/product-a
  -> https://old-domain.com/product-a
  -> https://www.old-domain.com/product-a
  -> https://www.new-domain.com/shop/product-a

قد يفتح الرابط، لكنه ليس نقلًا نظيفًا.

2. ضبابية path وquery

كثير من الفرق تختبر الصفحة الرئيسية فقط، ثم تكتشف لاحقًا أن deep links أو docs أو UTM لم تصل كما يجب.

3. wildcard لم يعد كافيًا

قاعدة مثل:

/blog/* -> /articles/*

تبدو مرتبة حتى:

• يتم دمج أقسام
• تختفي منتجات
• تظهر صفحات تحتاج استثناءات

عندها تحتاج إلى:

• mapping صريح
• أولويات
• validation
• خريطة تحويلات قابلة للمراجعة

4. التغييرات صعبة التدقيق

الـ merge في ملف config ليس سجل تدقيق للهجرة.

الأسئلة التي يريد الفريق إجابتها لاحقًا هي:

• من غيّر ماذا؟
• ما القواعد الجديدة؟
• ما الذي أزيل؟
• أين توجد التعارضات؟
• كيف يتم rollback؟

وهنا لا تساعد .htaccess وحدها كثيرًا.

الأخطاء الأكثر شيوعًا

فصل host وHTTPS والهدف النهائي إلى عدة قفزات

الأسوأ:

http://old-domain.com/docs/api
  -> https://old-domain.com/docs/api
  -> https://www.old-domain.com/docs/api
  -> https://www.new-domain.com/docs/api

الأفضل:

http://old-domain.com/docs/api
  -> https://www.new-domain.com/docs/api

اختبار الصفحة الرئيسية ونسيان الروابط المهمة

قد تبدو الصفحة الرئيسية صحيحة، بينما روابط المنتجات، المقالات، docs، والروابط القديمة من Google ليست كذلك.

فقدان المعلمات

إذا كانت attribution تعتمد على email أو QR أو paid social أو روابط الشركاء، فإن ضياع utm_ يحول الهجرة إلى مشكلة SEO ومشكلة reporting معًا.

عيش redirect map خارج الطبقة الحية

عندما تعيش الحقيقة في spreadsheet بينما القواعد الحية في ملف server، تتسع blind spots.

متى يحين وقت تغيير workflow؟

غالبًا عندما:

• تنقل مئات أو آلاف URL
• أكثر من فريق أو وكالة يغيّر القواعد
• تحتاج إلى import من CSV
• يجب التحقق من التعارضات قبل go-live
• يجب أن يكون rollback واضحًا
• لا تريد deploy للأصل عند كل تعديل

هنا تصبح UrlEdge منطقية:

• إدارة التحويلات بالجملة
• إدارة قواعد التحويل
• Permanent 301 Redirects

الخلاصة

السؤال الحقيقي ليس هل .htaccess جيدة أم سيئة.

السؤال الحقيقي هو:

هل ما تديره ما يزال مجرد بضع قواعد server يدوية، أم أنه أصبح مشروع routing له تبعات SEO وحملات وفرق متعددة؟

إذا كان الجواب هو الثاني، فـ snippet لم يعد هو الحل الكامل.