نقل موقع WordPress.com إلى WordPress.org ذاتي الاستضافة يعني الانتقال من استضافة WordPress.com إلى WordPress تثبته وتديره على شركة استضافة تختارها. العملية ليست دائمًا “Export XML ثم Import” فقط؛ هناك فرق بين نقل المحتوى ونقل نسخة كاملة من الموقع تشمل القالب والإضافات والمستخدمين.
هذا الدليل محدث لعام 2026 ويعتمد على وثائق WordPress.com الحالية. أزيلت منه عروض الاستضافة والأسعار الثابتة وScreenshots الخارجية القديمة وقوائم Plugins الترويجية لأنها لا تخدم قرار الهجرة وقد تتغير سريعًا.
المصدر الرسمي: WordPress.com – Export your website’s content وExport an entire website with a plugin.
WordPress.com وWordPress.org: ماذا يعني الانتقال؟
WordPress.org ليس شركة استضافة؛ هو مشروع WordPress المفتوح المصدر الذي تثبته على Hosting من اختيارك. بعد الانتقال تصبح مسؤولًا عن الاستضافة والتحديثات والنسخ الاحتياطي والأمان والتوافق بين القالب والإضافات.
لو لم تكن قد اخترت Hosting بعد، ابدأ من دليل اختيار استضافة WordPress في 2026. لا تختَر شركة الاستضافة فقط لأنها تقدم “Migration مجاني”؛ اختبر المتطلبات والدعم والنسخ الاحتياطي والأداء.
اختر مسار النقل المناسب
| حالتك | المسار المناسب | ماذا ينقل؟ |
|---|---|---|
| موقع WordPress.com عادي وتريد المحتوى | Standard Export / WXR | Posts, Pages, Comments وتفاصيل محتوى أخرى مدعومة |
| موقع WordPress.com يدعم Plugins وتريد نسخة كاملة | All-in-One WP Migration أوأداة Full-site مناسبة | Content + Media + Themes + Plugins + Users وفق الأداة والقيود |
| لديك Domain مخصص | Migration + DNS cutover | الموقع ثم توجيه الدومين للاستضافة الجديدة |
| المصدر عنوانه example.wordpress.com | Migration + Site Redirect عند الحاجة | إرسال الزيارات من عنوان WordPress.com القديم للجديد |
المسار A: نقل المحتوى باستخدام Export/Import
هذه الطريقة مناسبة عندما تريد نقل المحتوى إلى تثبيت WordPress جديد ولا تحتاج نسخ Theme/Plugins الحالية حرفيًا.
1. صدّر المحتوى من WordPress.com
من لوحة WordPress.com افتح أدوات التصدير واتبع مسار Export. التصدير القياسي ينتج ملف WXR/XML للمحتوى. في المواقع الكبيرة قد يصل Export كملف ZIP يحتوي أكثر من XML.
وفق وثائق WordPress.com الحالية، Standard Export مخصص أساسًا للمحتوى، وليس Full Backup للموقع بأكمله.
2. جهز WordPress على الاستضافة الجديدة
ثبت WordPress على Staging أودومين مؤقت قبل تغيير DNS. إذا تحتاج خطوات التثبيت نفسها، استخدم دليل تثبيت WordPress على الاستضافة 2026.
قبل الاستيراد اضبط على الأقل:
- HTTPS.
- Permalinks التي تريد استخدامها.
- Timezone واللغة.
- عدم فهرسة Staging.
- Backup baseline.
3. استورد WXR إلى WordPress الجديد
من لوحة الموقع الجديد اذهب إلى Tools → Import → WordPress، ثبت WordPress Importer إذا طلب النظام ذلك، ثم ارفع ملف XML.
أثناء الاستيراد راجع:
- ربط Authors بمستخدمين صحيحين.
- استيراد Attachments عندما يكون الخيار متاحًا.
- الصور بعد النقل، وليس فقط النصوص.
- Categories وTags.
- Navigation وWidgets؛ لا تفترض أنها ستنتقل بنفس الشكل.
ما الذي لا يضمنه WXR؟
Standard Export ليس نسخة Server/Image كاملة. لا تفترض أنه سينقل:
- Plugins وترخيصاتها.
- Theme files والتخصيصات الخاصة به.
- كل إعدادات Plugin.
- Server configuration.
- Custom code داخل ملفات النظام.
- أي Data خاصة بإضافة لا تدخل ضمن Export WordPress القياسي.
إذا كانت هذه الأشياء مهمة، استخدم Full-site migration بدل content-only.
المسار B: Full-site migration للمواقع التي تدعم Plugins
توثق WordPress.com حاليًا إمكانية استخدام All-in-One WP Migration لتصدير موقع WordPress.com كامل إلى Host آخر عندما يكون الموقع Plugin-enabled. هذا المسار يمكن أن يشمل Content وMedia وPlugins وThemes وUsers.
المصدر الرسمي: WordPress.com – Export an entire website with a plugin.
قبل الاعتماد عليه:
- تأكد أن خطتك في WordPress.com تسمح بتثبيت Plugins.
- راجع حجم ملف التصدير وحدود النسخة المجانية من أداة Migration.
- تأكد من مساحة التخزين وUpload limits على الاستضافة الجديدة.
- خذ نسخة منفصلة من المحتوى والبيانات الحرجة إن أمكن.
- اختبر النسخة المستوردة قبل تغيير DNS.
الصور والـMedia: لا تفترض نجاحها تلقائيًا
بعد أي Import افتح عينة من المقالات القديمة والجديدة وتحقق أن الصور أصبحت تعمل من الموقع الجديد، وليست مجرد روابط Hotlink ستستمر في تحميل الملف من WordPress.com.
افحص:
- Featured Images.
- Gallery images.
- صور داخل المحتوى.
- Download files.
- Alt text المهم.
- أي URL يبدأ من نطاق WordPress.com القديم.
إذا كنت تستخدم Domain مخصصًا
إذا كان الزوار يدخلون موقعك عبر نطاقك أنت مثل example.com، فهدفك عادة هو جعل نفس الدومين يشير إلى الاستضافة الجديدة بعد نجاح الاختبارات.
خطوات Cutover العامة:
- ابنِ واختبر الموقع الجديد قبل تغيير DNS.
- راجع SSL على الوجهة.
- قلل DNS TTL مسبقًا إذا كانت خطتك تحتاج ذلك.
- غيّر DNS/Nameservers حسب مزود الاستضافة والدومين.
- راقب HTTPS وRedirects وMail records بعد التحويل.
- لا تلغِ المصدر فورًا قبل التأكد أن كل شيء مستقر.
لا تستخدم Site Redirect كبديل عن DNS لمجرد أن لديك Custom Domain؛ خدمة Site Redirect في WordPress.com مخصصة لحالة مختلفة.
إذا كان عنوانك القديم example.wordpress.com
إذا كان المصدر عنوانًا مجانيًا من نوع example.wordpress.com وتريد إرسال الزوار إلى نطاق جديد، توفر WordPress.com حاليًا خدمة Site Redirect مدفوعة تعيد توجيه عنوان WordPress.com والـpermalinks إلى الوجهة الجديدة.
المصدر الرسمي: WordPress.com – Site Redirect. راجع السعر الحالي وقت التنفيذ بدل الاعتماد على رقم قديم في مقال.
وفق الوثائق الحالية، Site Redirect مخصص للانتقال من عنوان *.wordpress.com. إذا كان المصدر Custom Domain فتعامل مع الدومين وDNS/redirects حسب ملكيتك وإعدادك.
SEO: كيف تقلل الخسائر أثناء الهجرة؟
لا يوجد ضمان “صفر خسارة” لأي Migration، لكن يمكنك تقليل المخاطر إذا حافظت على URLs أوأنشأت Redirect Map دقيقة.
إذا بقي نفس الدومين ونفس المسارات
هذا أبسط سيناريو. حافظ على Slugs وPermalink structure قدر الإمكان، ثم اختبر HTTP status وCanonical وSitemap بعد الإطلاق.
إذا تغير الدومين أوالمسارات
أنشئ Mapping من كل URL قديم مهم إلى أقرب URL جديد. لا تحول كل شيء إلى Homepage.
| URL قديم | الوجهة |
|---|---|
| مقال | نفس المقال الجديد |
| صفحة خدمة | نفس الخدمة أوأقرب بديل حقيقي |
| تصنيف | التصنيف المقابل |
| صفحة ألغيت بلا بديل | قرار يدوي؛ ليس Homepage تلقائيًا |
للتفاصيل حول Canonical وSitemap وRobots وRedirects بعد النقل استخدم دليل Technical SEO.
Checklist SEO بعد Cutover
- Homepage وURLs المهمة ترجع 200.
- 301s تعمل Hop واحد عند الحاجة.
- لا يوجد Noindex من Staging.
- Canonical تشير للدومين الصحيح.
- XML Sitemap تستخدم URLs الجديدة.
- robots.txt لا يمنع أقسامًا مهمة.
- Search Console property والدومين/الـsitemap محدثة حسب السيناريو.
- Analytics/Tag Manager يعملان مرة واحدة فقط.
- 404 logs تتم مراقبتها خلال الأيام الأولى.
ماذا عن Subscribers؟
المشتركون في WordPress.com ليسوا مجرد Posts داخل WXR في كل السيناريوهات. إذا لديك Followers/Email subscribers كجزء مهم من المشروع، راجع وثائق WordPress.com وJetpack الحالية قبل Cutover، وحدد كيف سيتم نقلهم أوإعادة الاشتراك بما يتوافق مع الخصوصية وسياسة البريد.
لا أضع Workflow ثابتًا هنا لأن طريقة Subscribers تختلف حسب الخدمات والميزات المفعلة وقت النقل.
هل أنقل كل Plugins وThemes؟
لا. الهجرة فرصة لمراجعة Technical Debt. إذا كان Full-site export يحمل Plugins قديمة أوغير مستخدمة، لا تجعل “النسخة المطابقة” هدفًا أعلى من سلامة الموقع.
على Staging:
- حدّث Core/Plugins/Themes.
- احذف ما ثبت أنه غير مستخدم.
- راجع Licenses.
- اختبر PHP compatibility.
- راجع Cache/Security plugins لأن البيئة الجديدة قد توفر نفس الوظائف على الخادم.
خطة تنفيذ عملية
- جرد المحتوى والدومين والPlugins والخصائص الحرجة.
- اختر content-only أوfull-site migration.
- جهز Hosting وWordPress الجديد.
- نفذ Import على Staging.
- راجع الصور والروابط والUsers.
- اختبر Forms/Login/Search وWooCommerce إن وجد.
- جهز Redirect/DNS plan.
- نفذ Cutover.
- راقب 404 وSearch Console وAnalytics.
- احتفظ بالمصدر والنسخ الاحتياطية حتى تستقر الوجهة.
أخطاء شائعة
- الاعتقاد أن XML Export هو Full Backup.
- الاعتماد على Screenshots قديمة لمسار WordPress.com.
- إغلاق الموقع القديم قبل اختبار الصور والمحتوى.
- تغيير Permalinks والدومين والتصميم في نفس اللحظة بلا Mapping.
- إرسال كل 404 إلى Homepage.
- ترك Staging noindex على Production.
- تشغيل Analytics القديم والجديد معًا فتتكرر الأحداث.
- شراء استضافة بسبب Affiliate recommendation بدل متطلبات المشروع.
الخلاصة
نقل WordPress.com إلى WordPress.org في 2026 يبدأ بتحديد ماذا تريد نقله فعلًا: محتوى فقط عبر WXR، أمموقع كامل عبر Migration plugin عندما تسمح الخطة بذلك. ابنِ الوجهة على Staging، اختبر Media والروابط والوظائف، ثم نفذ DNS/301 بطريقة تحفظ URLs قدر الإمكان. لا تغلق المصدر أوتغير الدومين قبل أن تكون لديك نسخة قابلة للاستعادة وخطة رجوع واضحة.
