الانتقال من WordPress إلى Next.js: كيف تنتقل دون أن تخسر ترتيبك في نتائج البحث

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

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

ابقَ على WordPress وقوِّه عندما يكون العكس صحيحاً: احذف الإضافات غير المستخدمة، واستخدم استضافة مُدارة موثوقة، وطبّق الترقيعات خلال أيام، واحتفظ بنسخ احتياطية، وضع جدار حماية لتطبيقات الويب أمام الموقع. نادراً ما تكون ثغرة أمنية وحدها سبباً للانتقال. عندما تظهر ثغرة في الجوهر مثل CVE-2026-87902، فالمهمة الأولى هي التحديث؛ أما الانتقال فقرار منفصل يمكنك اتخاذه بهدوء لاحقاً. يتناول دليلانا عن أمان WordPress مقارنةً بالموقع المخصص وعن CVE-2026-87902 الأمرين معاً.

هناك مساران رئيسيان. في الأول يبقى WordPress نظام CMS بنمط headless: يحتفظ المحررون بلوحة إدارة WordPress، وتجلب واجهة أمامية مبنية بـ Next.js المحتوى وتبني الصفحات العامة. تصف وثائق المطورين الخاصة بـ WordPress واجهة REST API لديها بأنها وسيلة لنقل محتوى WordPress إلى تطبيقات منفصلة تماماً، ويمكن استخدامها من أي لغة قادرة على إرسال طلبات HTTP وقراءة JSON. في المسار الثاني يُستغنى عن WordPress، وينتقل المحتوى إلى نظام CMS بنمط headless آخر أو إلى لوحة إدارة مخصصة مبنية لفريقك.

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

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

1. 1

   تدقيق الموقع

   حصر كل صفحة ونوع محتوى ونموذج ودور مستخدم وإضافة، وتدوين ما تفعله كل إضافة فعلاً للعمل. جمع الروابط الحالية من ملف sitemap ومن عملية زحف ومن Search Console حتى لا تُنسى صفحات لها زيارات أو روابط واردة.

2. 2

   ربط الروابط القديمة بالجديدة

   إعطاء كل عنوان قديم وجهة في جدول بيانات واحد: المقالات والصفحات وأرشيفات التصنيفات والوسوم وصفحات الكتّاب وخلاصات RSS وملفات الوسائط في /wp-content/uploads/. يصبح كل سطر تحويلاً دائماً.

3. 3

   إعادة البناء وتحديد طريقة تحرير المحتوى

   إعادة بناء القوالب في Next.js والاختيار بين WordPress بنمط headless أو نظام CMS آخر بنمط headless أو لوحة إدارة مخصصة، بحسب من يحرر وكم مرة.

4. 4

   نقل المحتوى والمستخدمين والبيانات

   استيراد المقالات والصفحات والوسائط والحسابات، ومقارنة عينة يدوياً بالموقع القديم، وإعادة بناء تسجيل الدخول بنموذج الصلاحيات الذي تحتاجه، مثل الصلاحيات القائمة على الأدوار أو MFA أو SSO.

5. 5

   الإطلاق والمراقبة

   التحويل إلى الموقع الجديد، واختبار التحويلات، وإرسال ملف sitemap الجديد، ومراقبة الأخطاء والصفحات المفقودة في Search Console. بعد الإطلاق تستمر تحديثات الاعتماديات والمراقبة كجزء من العمل.

تتعامل Google مع تغيير المنصة الذي يغيّر الروابط على أنه نقل للموقع. يوصي دليل Search Central الخاص بنقل المواقع مع تغيير الروابط (المحدَّث في 20 أغسطس 2026) بتحويلات دائمة من جهة الخادم مثل 301 أو 308، وبخريطة كاملة تربط الروابط القديمة بالجديدة، وبالإبقاء على التحويلات أطول مدة ممكنة، سنة على الأقل. ويذكر أيضاً أن الموقع متوسط الحجم قد يحتاج إلى بضعة أسابيع أو أكثر قبل أن تعرض Google الروابط الجديدة بدل القديمة، لذا فإن بعض التذبذب بعد الإطلاق أمر طبيعي.

• حوّل كل رابط قديم مباشرة إلى أقرب صفحة جديدة له. تجنب سلاسل التحويل، ولا ترسل روابط قديمة كثيرة إلى الصفحة الرئيسية.
• في Next.js، اكتب التحويلات في next.config مع permanent: true، فيُعاد الرمز 308. تشير وثائق Next.js إلى أن منصات الاستضافة قد تضع حداً لهذه القائمة (تسمح Vercel بـ 1,024) وتقترح خريطة تحويلات يقرؤها Proxy عند تجاوز 1,000 تحويل.
• امنح كل صفحة جديدة وسم canonical يشير إليها نفسها. في Next.js يُضبط ذلك عبر alternates.canonical في Metadata API.
• أنشئ ملف sitemap للروابط الجديدة باستخدام app/sitemap.ts وأرسله في Search Console، واحتفظ بملف sitemap القديم حتى يُرسل الجديد.
• استخدم تحويلات من جهة الخادم لا تحويلات JavaScript. تقول وثائق Google عن التحويلات إن تحويلات JavaScript لا تُستخدم إلا إذا تعذّر التحويل من جهة الخادم أو عبر meta refresh.
• أبقِ الموقع موثَّقاً في Search Console، وراجع تقارير الفهرسة وملفات sitemap أسبوعياً بعد الإطلاق، وحدّث الروابط الداخلية حتى لا يعتمد الموقع على تحويلاته الخاصة.

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

يشغّل WordPress multisite عدة مواقع من تثبيت واحد. تصف وثائق WordPress الشبكات بأنها قائمة على المسارات (مجلدات فرعية) أو على النطاقات (نطاقات أو نطاقات فرعية)، ويحتفظ كل موقع بجداول المحتوى الخاصة به، ولا يُشارَك إلا جدول المستخدمين. وهذا يحدد شكل الخطة.

• تعامل مع كل موقع كعملية انتقال مستقلة، بخريطة روابط وملف sitemap وفحوص في Search Console خاصة به.
• قرّر مبكراً هل يبقى المستخدمون المشتركون في نظام حسابات واحد أم يُفصلون لكل موقع، وكيف سيدير مسؤولو الشبكة جميع المواقع بعد ذلك.
• احصر الإضافات والقوالب المفعّلة على مستوى الشبكة، لأن إضافة واحدة قد تدعم وظائف في كل المواقع.
• يمكن لتطبيق Next.js واحد أن يخدم عدة نطاقات، ويمكن لتحويلاته أن تطابق اسم المضيف، فيحمل مستودع شيفرة واحد خرائط التحويل لجميع المواقع.
• انقل موقعاً واحداً أولاً، وراقب زيارات البحث إليه بضعة أسابيع، ثم انقل البقية.

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

• هل خريطة التحويلات الكاملة جزء من النطاق المكتوب، ومن يراجعها بعد الإطلاق؟
• كيف سيحرر فريقنا المحتوى وينشره بعد الإطلاق، وهل ستدربونه؟
• أي الإضافات ستُعاد بناؤها، وأيها ستُستبدل بخدمة، وأيها سيُستغنى عنها؟
• كيف تُنقل حسابات المستخدمين وتسجيلات الدخول، وماذا سيرى المستخدمون عند أول تسجيل دخول؟
• هل سيبقى النطاق والروابط كما هي، وإلى متى ستراقبون البحث بعد الإطلاق؟
• من يملك الشيفرة والاستضافة ونظام CMS وحسابات النطاق؟
• أي ساعات من يوم عملنا تتداخل مع ساعات عملكم، وما سرعة ردكم؟
• من يحدّث الاعتماديات بعد الإطلاق، وهل ذلك منصوص عليه في العقد؟
• هل يمكننا رؤية عمليات انتقال أو منصات محتوى بنيتموها؟

تعتمد المدة والتكلفة على المحتوى والروابط أكثر من اعتمادها على الشيفرة. أهم العوامل هي:

• عدد قوالب الصفحات المختلفة وأنواع المحتوى المخصصة.
• عدد الروابط التي تحتاج إلى تحويل، بما فيها الأرشيفات وملفات الوسائط.
• النماذج والمدفوعات والعضويات وتكاملات CRM أو ERP التي كانت الإضافات تتولاها.
• هل يبقى WordPress نظام CMS بنمط headless أم يُستبدل.
• حسابات المستخدمين ونموذج تسجيل الدخول، خاصة مع MFA أو SSO.
• شبكات multisite واللغات الإضافية، ولكل منها روابطه الخاصة.

تتفاوت الأرقام المنشورة كثيراً ومعظمها صادر عن وكالات. على سبيل المثال، نشرت Kolonell، وهي استوديو ويب يعمل عن بُعد، في 8 أكتوبر 2026 تقديراً للشركات الصغيرة في المملكة المتحدة: من 13,000 إلى 30,000 جنيه إسترليني دون ضريبة القيمة المضافة للانتقال إلى Next.js بنمط headless، خلال 10–14 أسبوعاً (نحو أسبوعين للتدقيق وتحديد النطاق، و6–8 أسابيع للتطوير والنقل، و2–4 أسابيع للاختبار والإطلاق على مراحل). اعتبر ذلك تسعير وكالة واحدة لا سعر سوق. وتبيع بعض الوكالات «سبرنت انتقال» بسعر ثابت؛ اسأل عمّا يشمله، خاصة التحويلات وتدريب المحررين.

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

• خدمة الانتقال من WordPress إلى Next.js (بالإنجليزية)
• WordPress أم موقع مخصص: هل الانتقال أكثر أماناً؟ (بالإنجليزية)
• ثغرة WordPress CVE-2026-87902: ماذا تفعل (بالإنجليزية)
• ما هو نظام CMS بنمط headless؟
• احجز استشارة مجانية ومراجعة لموقع WordPress (بالإنجليزية)

• Google Search Central: Site moves with URL changes (updated 20 August 2026)
• Google Search Central: Redirects and Google Search (updated 14 April 2026)
• Next.js docs: redirects in next.config.js (updated 30 June 2026)
• Next.js docs: How to handle redirects in Next.js (updated 19 August 2026)
• Next.js docs: sitemap.xml file convention (updated 18 August 2026)
• Next.js docs: generateMetadata, alternates and canonical (updated 19 August 2026)
• WordPress Developer Resources: REST API Handbook (accessed 1 November 2026)
• WordPress Developer Resources: Multisite (accessed 1 November 2026)
• Kolonell: WordPress to Next.js migration cost for UK SMBs, agency estimate (8 October 2026)