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

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

ابدأ من خريطة الروابط قبل أن يُكتب سطر واحد من الكود

ما تفعله ليس تغيير تصميم. دليل Google لنقل المواقع يضع أي تعديل على مسارات الروابط داخل النطاق الواحد في خانة نقل الموقع، فانتقال صفحة منتج من shop.com/item?id=1023 إلى shop.com/products/blue-shirt نقلٌ مكتمل في نظر الفهرس، حتى لو بقي اسم النطاق كما هو ولم يلاحظ عميلك شيئًا.

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

من أين تأتي قائمة الروابط القديمة

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

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

نوع الصفحةشكلها المعتاد على منصة جاهزةما يجب أن يحدث عند النقل
صفحة منتج/products/اسم-المنتجتحويل 301 إلى رابط المنتج الجديد، مع رابط واحد لكل منتج وليس رابطين
صفحة تصنيف/collections/اسم-التصنيفتحويل 301 إلى التصنيف المقابل في النظام الجديد
رابط فلترة أو فرز/collections/…?sort_by=قرار مُسبق: توحيده مع رابط التصنيف، أو تركه بلا فهرسة
مقال مدونة/blogs/news/اسم-المقالتحويل 301 إلى مسار المدونة الجديد
صفحة سياسات/pages/shipping-policyتحويل 301، وهي من أكثر الصفحات المحفوظة في المفضلة
صور ومرفقاتنطاق التخزين الخاص بالمنصةرفعها على تخزينك الجديد قبل التحويل، لا الاعتماد على روابط المنصة
منتج أُلغي نهائيًالا مقابل له في النظام الجديدرمز 404 أو 410، لا تحويل إلى الصفحة الرئيسية

قواعد التحويل التي تستحق أن تُكتب في المواصفات

تعامل مع هذه النقاط بوصفها شروط قبول للتسليم، لا نصائح عامة:

  • استخدم تحويلًا دائمًا من جهة الخادم. التوثيق يوصي بالرمزين 301 و308 متى أمكن تقنيًا، لأن التحويل الدائم هو الإشارة التي يعتمدها الفهرس لاعتبار الرابط الجديد هو الأساسي.
  • لا تبنِ سلاسل تحويل. Googlebot يتبع حتى عشر قفزات، لكن التوصية أن يصل الرابط إلى وجهته النهائية مباشرة. وإذا تعذّر ذلك فالسقف المذكور ثلاث قفزات يُفضَّل ألا تُتجاوز، وخمس لا يصح بلوغها.
  • المحذوف يُعلن محذوفًا. المحتوى الذي لن ينتقل يجب أن يعيد رمز 404 أو 410، وتحويل كل منتج ملغى إلى الصفحة الرئيسية يخلق صفحات لا علاقة لها بما بحث عنه الزائر.
  • كل رابط جديد يحمل canonical ذاتية المرجعية، ولو كان لمتجرك نسخة إنجليزية فحدِّث وسوم hreflang لتشير إلى الروابط الجديدة لا القديمة.
  • احتفظ بالتحويلات طويلًا. التوثيق يطلب إبقاءها أطول فترة ممكنة، وبمدة «لا تقل عن سنة واحدة»، لأن هذه النافذة هي ما يسمح بانتقال كل الإشارات إلى الروابط الجديدة. ومن زاوية المستخدم، يُنصح بإبقائها بلا تاريخ انتهاء.

نقطتان تريحان الميزانية والأعصاب. الأولى أن التحويل الدائم لا يُفقدك قوة الروابط، وللتوثيق فقرة كاملة تطمئن صاحب الموقع وتقرر أن التحويلات الدائمة «لا تؤثر سلبًا في PageRank». والثانية أن أداة تغيير العنوان في Search Console لا تلزم إلا إذا تغيّر النطاق أو النطاق الفرعي، أما تبديل المسارات داخل النطاق الواحد فلا يحتاجها، وهي حالة أغلب من يترك منصة جاهزة ويحتفظ بدومينه.

ماذا تفعل في اليوم التالي للتحويل

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

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

ما الذي يخرج من المنصة فعلًا؟

هنا مصدر أغلب المفاجآت. أنت لا تنقل المتجر كوحدة واحدة، بل تنقل ما تسمح المنصة بتصديره في صيغة قابلة للاستيراد، وما تستطيع أنت سحبه عبر واجهاتها البرمجية. الفرق بين الاثنين كبير.

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

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

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

هل تخطط لبناء أو تطوير مشروع رقمي؟

فريق سنابل يوفر لك دراسة فنية مخصصة لتحديد التقنيات المناسبة وتكلفة التنفيذ الدقيقة.

تواصل عبر واتساباستكشف خدماتنا

تفصيل صغير يوفّر يومًا من الفوضى: استيراد الطلبات القديمة قد يُطلق إشعار طلب جديد عن كل طلب مستورد. عطّل إشعارات الطلبات قبل بدء الاستيراد، وإلا استيقظ فريقك على آلاف الرسائل.

الحسابات وكلمات المرور: البند الذي يغضب العملاء

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

ما ينتقل هو الاسم والبريد والهاتف والعناوين والوسوم، وما لا ينتقل هو مفتاح الدخول. خطّط للأمر كتجربة استخدام لا كرسالة بريد:

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

الدفع والشحن: حسابات لا تنتقل مع الكود

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

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

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

الفوترة الإلكترونية: الربط يُعاد من النظام الجديد

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

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

خطة التحويل: من التشغيل المتوازي إلى لحظة الدومين

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

وقبل التحويل بيوم:

  1. اخفض مدة TTL لسجلات DNS. هذه القيمة تحدد كم يبقى السجل مخزّنًا مؤقتًا عند مزوّدي الخدمة، وتوثيق Cloudflare يشرح أن القيمة الأطول تؤخّر وصول أي تعديل على السجل إلى المستخدمين. قيمة منخفضة قبل التحويل تعني وصولًا أسرع، وتراجعًا أسرع لو احتجت.
  2. افصل الدومين عن المنصة القديمة قبل توجيهه إلى الخادم الجديد. تحذير شوبيفاي في هذا واضح: افصل الدومينات المرتبطة بالمنصات السابقة قبل النقل تفاديًا لأخطاء شهادة SSL. الشهادة على المتجر الجديد يجب أن تكون صادرة وفعّالة قبل أن يصل إليه أول زائر، لا بعده.
  3. جمّد التعديلات على المتجر القديم في نافذة زمنية معلومة، وزامن الطلبات التي دخلت في الساعات الأخيرة قبل فتح الجديد.
  4. أزِل أي قاعدة noindex أو حظر في robots.txt كنت تستخدمه أثناء التطوير. Google تضع هذا في مقدمة الأخطاء الشائعة التي تمنع فهرسة الموقع الجديد بالكامل.

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

قائمة فحص قبل التحويل وبعده

قبل التحويل

  • خريطة روابط مكتملة، كل رابط قديم له وجهة واحدة، ولا سلاسل تحويل.
  • نسخة احتياطية كاملة من كل ما صُدِّر، ومن قاعدة بيانات النظام الجديد (خطة النسخ الاحتياطي).
  • الصور مرفوعة على تخزينك الجديد، والمتجر القديم ما زال مفتوحًا.
  • شهادة SSL فعّالة على الدومين، وقيمة TTL منخفضة.
  • عملية دفع حقيقية مُختبَرة من طرفها إلى طرفها، وفاتورة صادرة بنجاح من بيئة الاختبار.
  • إشعارات الطلبات معطّلة أثناء استيراد الطلبات القديمة.
  • ملكية الموقعين مثبتة في Search Console.

بعد التحويل مباشرة

  • فحص عيّنة من كل نوع رابط: منتج، تصنيف، مقال، صفحة سياسات، صورة.
  • إزالة قواعد noindex وحظر robots.txt، وإرسال خريطة الموقع الجديدة.
  • طلب اختباري حقيقي يمر بالدفع والفاتورة والشحن من الحساب النهائي.
  • مراقبة أخطاء 404 وسجلات الخادم يوميًا في الأسبوع الأول.
  • تحديث الروابط الداخلية وروابط حساباتك على منصات التواصل وحملاتك الإعلانية، فالتحويل حل مؤقت لا بديل دائم.
  • مقارنة سرعة الصفحات بما كانت عليه (معايير Core Web Vitals)، ومراجعة إعدادات الاستضافة الجديدة.

الهجرة الجيدة لا يلاحظها أحد. العميل يجد الرابط نفسه يعمل، ويدخل بحسابه بعد إعادة تعيين واحدة، ويستلم طلبه في موعده، بينما يتحرك الفهرس تدريجيًا نحو الروابط الجديدة على مدى أسابيع.

إذا كنت تخطط لنقل متجرك إلى نظام مخصّص، أرسل رابط متجرك الحالي وعدد منتجاتك وتصنيفاتك إلى فريق سنابل، وسيصلك خلال 24 ساعة تصوّر أولي لخطة النقل وتقدير للمدة والتكلفة، بلا مقابل ولا التزام.

المصادر