تدقيق تحويلات 301 في ووردبريس: استرجع روابطك القديمة

فيه موقع في حتة ما لسه حاطط لينك ووردبريس للمحتوى المؤرخ مثل التدوينات والأخبار والشروحات. تُرتّب زمنيًا وتُنظَّم بالتصنيفات والوسوم وتظهر في الأرشيف وخلاصات RSS، بخلاف الصفحات الثابتة.">لمقالة انت مسحتها من سنين. كل واحد بيدوس عليه بيقع في صفحة 404، والقيمة اللي الرابط ده كان ممكن يديها لموقعك بتروح على الأرض.

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

الحالة: مدونة عمرها 15 عامًا

يعرض كاتب المصدر تجربته مع مدونة منصة ألعاب ورق برازيلية تعمل منذ 2010. بدأت على Blogger ثم انتقلت إلى ووردبريس (WordPress)، وتغيّرت بنية الروابط الدائمة (Permalink) أكثر من مرة، فتراكمت خلفها آلاف الروابط الميتة.

النتيجة بعد يوم عمل: 29 تحويلًا مدروسًا فقط من بين أكثر من ألف رابط معطل، مع اكتشاف خطأ CSS كان يولّد 404 في كل زيارة. الأرقام هنا مهمة لأنها تثبت فكرة واحدة: معظم الروابط الميتة لا تستحق تحويلًا.

الخطوة 1: اجرد كل رابط وُجد يومًا

السيو تنشئها تلقائيًا، وترسلها أنت عبر Google…">خريطة الموقع (Sitemap) تعرض الروابط الحية فقط. للحصول على السجل التاريخي، استخدم واجهة CDX في أرشيف الإنترنت (Wayback Machine CDX API)، وهي مجانية:

curl -s "https://web.archive.org/cdx/search/cdx?url=example.com&matchType=domain&fl=original&collapse=urlkey" > wayback_urls.txt

في الحالة المعروضة أعاد الأمر 40,005 رابط. بعد حذف الملفات الثابتة وصفحات البحث واستدعاءات API والروابط المكررة بمعاملات الاستعلام، بقي 2,862 رابطًا مرشحًا.

افحص حالة كل رابط على الدومين الحالي بـ curl -L. في التجربة أعاد 473 رابطًا الرمز 200، و1,107 أعادت 404.

ملاحظة للمواقع العربية: الروابط الدائمة بالعربية تُحفظ مُرمَّزة مثل %D9%88%D9%88.... قارن الروابط في الجرد بصيغتها المرمّزة وغير المرمّزة معًا، لأن الأرشيف قد يحفظ إحداهما وإضافة التحويلات تطابق الأخرى.

الخطوة 2: ابحث عن دليل أن الرابط الميت ما زال مستخدمًا

الأرشيف يخبرك بما كان موجودًا، لا بمن يربط إليه. استخدم ثلاثة مصادر:

• الروابط الخارجية: بيانات Common Crawl تعرض الدومينات التي تربط إليك. ادخل إلى كل دومين، وجد الصفحة التي فيها الرابط، وافحص الـ href الفعلي.
• سجل 404: إضافات التحويل مثل Redirection تحتفظ بسجل لأخطاء 404. استبعد البوتات وطلباتك وطلبات الفحص الأمني، ثم اقرأ مصدر الإحالة (Referrer).
• التاريخ: عدد مرات الأرشفة مؤشر تقريبي على الشعبية؛ رابط قواعد لعبة قديم أُرشف 47 مرة مثلًا.

من هذه المصادر خرجت قائمة قصيرة: صفحتان خارجيتان تربطان إلى مقالات محذوفة، و11 مقالة تغيّر التاريخ في روابطها مع بقاء الـ woocommerce أو wordpress-seo لإضافة Yoast. عليه تُبنى كل أدوات الفحص.">الإضافات والقوالب والمستخدمين والإعدادات، وما يظهر فيها يختلف حسب دور المستخدم.">لوحة التحكم عبر add_menu_page، وإذا تكرر مع إضافة أخرى تختفي إحدى الصفحتين، لذلك يُسبق دائمًا ببادئة باسم الإضافة.">slug نفسه، وروابط تتكرر في سجل 404.

لا تتوقع الكمال هنا. Common Crawl عيّنة لا تغطي كل الروابط، وأداة فحص الروابط في Search Console قد تقول عن رابط تعرف أن له باك لينك إنه «غير معروف لـ Google».

الخطوة 3: اختر الوجهة حسب الموضوع

لا ترسل كل رابط ميت إلى الصفحة الرئيسية. Google يميل إلى اعتبار التحويل البعيد عن الموضوع خطأ 404 الناعم (Soft 404)، والقارئ لن يجد المقالة التي ضغط عليها أصلًا.

القاعدة: حوّل فقط حين توجد صفحة حية تغطي الموضوع نفسه:

افتح كل وجهة وتأكد أنها ترد بـ 200 دون أي قفزة، وراجع وسم <title> لتتأكد من تطابق الموضوع.

وما الذي يُترك؟ مقالات لا بديل حيًا لها، مثل الإعلانات القديمة وتصنيفات شهرية، وصفحات أرشيف ووسوم بلا روابط خارجية. بعض الروابط الميتة مكانها الصحيح هو 404.

الخطوة 4: قواعد مطابقة تامة، بلا Regex

المقالات التي تغيّر تاريخها تبدو مثالية لتعبير نمطي واحد:

^/blog/d{4}/d{2}/d{2}/(.+)$  ->  /blog/$1

هذا التعبير يصنع حلقة التحويل (Redirect Loop). ووردبريس نفسه يحوّل /blog/<slug>/ إلى الرابط المؤرّخ الحالي، والتعبير سيطابق الروابط الحية المؤرخة أيضًا ويرسلها إلى الصيغة غير المؤرخة، فيعيدها ووردبريس فورًا.

لذلك اجعل كل قاعدة مطابقة تامة لرابط واحد، وكلها تحويل دائم 301 (301 Redirect)، مع:

• تجاهل معاملات الاستعلام عند المطابقة، فيعمل الرابط مع ?utm_source=....
• المطابقة بالشرطة المائلة الأخيرة وبدونها.
• عنوان مشترك لكل القواعد الجديدة داخل الإضافة، ليسهل التراجع عنها دفعة واحدة.

الخطوة 5: فحص مسبق قبل كتابة أي قاعدة

قبل إنشاء القواعد، اطرح ثلاثة أسئلة على كل واحدة:

1. هل يعيد المصدر 404 بالشرطة المائلة وبدونها؟ إن لم يفعل، فهناك شيء آخر يتعامل معه.
2. هل تعيد الوجهة 200 مباشرة؟ إن لم تفعل، ستصنع سلسلة التحويلات (Redirect Chain).
3. هل الوجهة نفسها مصدر في قاعدة أخرى؟ إن كانت، فهذه حلقة.

هذا السكربت من المصدر يلخص الفحص (بايثون مختصر، ودالة status تغلّف أمر curl):

sources = {src for _, src, _ in rules}
for block, src, dst in rules:
    with_slash    = status(SITE + src)          # curl -s -o /dev/null -w '%{http_code}'
    without_slash = status(SITE + src.rstrip("/"))
    target        = status(SITE + dst)
    ok = (with_slash == "404" and without_slash == "404"
          and target == "200" and dst not in sources)
    print("OK" if ok else "XX", block, src)

الخطوة 6: قاعدة استطلاعية أولًا، ثم تحقق من كل قاعدة

أنشئ قاعدة واحدة فقط وتحقق منها من البداية للنهاية، فهذه هي التجربة الاستطلاعية (Canary Deployment). بعدها أنشئ الباقي واحدة تلو الأخرى، يدويًا أو عبر REST API الخاص بإضافة التحويلات، وأوقف العملية عند فشل أي شرط.

بعد كل قاعدة، اختبر ثلاث صيغ للرابط:

variants = [src, toggle_trailing_slash(src), src + "?utm_source=x"]

for v in variants:
    target = SITE + dst                    # Location comes back absolute
    head  = curl_head(SITE + v)
    final = curl_follow(SITE + v)          # -L --max-redirs 5 -> code, url, hops
    ok = (head.status == 301
          and head.location == target      # exact, not "close enough"
          and final == (200, target, 1))   # one hop, ends on a 200

المطلوب: رد 301، وعنوان Location يطابق الوجهة حرفيًا، ثم الوصول إلى 200 في قفزة واحدة. سجّل أيضًا ترويسة x-redirect-by لتعرف هل ردّت الإضافة أم طبقة قبلها مثل Cloudflare. في الحالة المعروضة نجحت 29 قاعدة في 87 اختبارًا.

ثم افحص مسحًا نهائيًا: صفر قواعد Regex، صفر وجهات هي مصادر في الوقت نفسه، وكل الوجهات 200 مباشرة. وأصلح الروابط الداخلية من مصدرها في المقالات بدل الاعتماد على التحويل.

الخطوة 7: نسخة احتياطية وخطة تراجع

قبل أي تعديل، صدّر قواعد التحويل الحالية إلى ملف JSON واحفظ بصمته (sha256)، وكرر التصدير بعد الانتهاء. التراجع حينها بسيط: فلتر القواعد بالعنوان المشترك وعطّلها، فتعود الروابط القديمة إلى 404 كما كانت.

مكسب جانبي: خطأ 404 في كل زيارة

سجل 404 كان مليئًا بطلبات لرابط الصفحة نفسها منتهيًا بعلامة &، ومصدر الإحالة هو الصفحة ذاتها. لا يوجد رابط ظاهر كهذا؛ السبب كان داخل <head>.

القالب يملك حقل CSS مخصصًا خاصًا به في أداة التخصيص، وكان يطبع هذا:

.wp-block-search__button {
  background-image: url('images/lupinha.png') !important;
}

القالب نظّف الحقل بالدالة esc_attr، فتحولت كل علامة ' إلى '. المتصفح لا يفك ترميز HTML داخل <style>، فيقرأ الرابط حرفيًا كمسار نسبي، وعلامة # تبدأ جزءًا يُحذف، فيبقى طلب إلى <رابط الصفحة>&:

from urllib.parse import urljoin, urldefrag

page = "https://example.com/blog/some-post/"
print(urldefrag(urljoin(page, "'images/lupinha.png'")).url)
# https://example.com/blog/some-post/&

النتيجة: كل زيارة تشغّل ووردبريس كاملًا لتوليد صفحة 404 إضافية، وأيقونة البحث مكسورة. الإغراء هنا تحويل .../& إلى الصفحة، لكنه يستبدل 404 بتحويل 301 وصفحة كاملة في كل زيارة، والأيقونة تبقى مكسورة.

الإصلاح الصحيح كان من جزأين:

• البيانات: تغيير السطر إلى رابط مطلق بلا علامات تنصيص، بعد حفظ نسخة من القيمة القديمة.
• السبب: استبدال esc_attr في دالة التنظيف بغلاف حول wp_strip_all_tags الذي يحذف وسوم HTML ويحتفظ بعلامات التنصيص.

في Elementor: إن كنت تكتب CSS مخصصًا في Site Settings > Custom CSS أو في حقل Custom CSS لأي عنصر، استخدم روابط مطلقة للصور الخلفية. وإن رأيت في سجل 404 طلبات من الصفحة لنفسها، فابحث أولًا في CSS المخصص والقالب، لا في الروابط.

قائمة المراجعة

• [ ] اجرد الروابط التاريخية من Wayback CDX واحذف الملفات وصفحات البحث والمعاملات.
• [ ] افحص الحالة الحالية لكل رابط مرشح.
• [ ] ابحث عن دليل استخدام: href خارجي فعلي، أو مصدر إحالة في سجل 404، أو تاريخ أرشفة قوي.
• [ ] اختر الوجهة حسب الموضوع وتأكد أنها 200 مباشرة، وإلا اترك الرابط.
• [ ] قواعد مطابقة تامة فقط، بلا Regex على روابط ووردبريس.
• [ ] فحص مسبق: المصدر 404، الوجهة 200، ولا وجهة هي مصدر.
• [ ] نسخة احتياطية JSON مع بصمة، وعنوان مشترك للقواعد الجديدة.
• [ ] قاعدة استطلاعية أولًا، ثم البقية مع اختبار ثلاث صيغ لكل رابط.
• [ ] أصلح الروابط الداخلية من مصدرها.
• [ ] اتبع الرابط الخارجي الحقيقي وتأكد أنه يصل إلى 200.
• [ ] صفحة تطلب نفسها في سجل 404 تعني خطأ برمجيًا، لا باك لينك.

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

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

س: ما الفرق بين تحويل 301 و302؟
ج: 301 تحويل دائم ينقل قيمة الرابط إلى العنوان الجديد، و302 مؤقت يُستخدم حين تنوي إعادة الصفحة الأصلية. للروابط المحذوفة نهائيًا استخدم 301.

س: كيف أعرف الروابط الخارجية التي تشير إلى صفحات محذوفة مجانًا؟
ج: اجمع بين بيانات Common Crawl وتقرير الروابط في Search Console وسجل 404 في إضافة التحويلات. لن تجد كل الروابط، لكنك ستجد الأهم منها.

س: لماذا تظهر رسالة كثرة التحويلات بعد إضافة قاعدة جديدة؟
ج: غالبًا لأن القاعدة تطابق الوجهة نفسها أو يتعارض معها تحويل يقوم به ووردبريس تلقائيًا. استبدل قواعد Regex بقواعد مطابقة تامة وافحص أن الوجهة ليست مصدرًا.

الخلاصة

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

مرجع المقال (بالإنجليزية): Your old URLs still earn links: a 301 audit of a 15+ year-old blog
المقال ده مش ترجمة حرفية: متكيّف للقارئ العربي ومضاف عليه سياق ووردبريس وElementor وJetEngine.