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

محركات البحث بتعتبر أي تغيير في اللينكات أو المحتوى أو طريقة العرض أو قابلية الزحف نقل. والخطورة بتختلف حسب النوع، فحدد نوع نقلتك قبل ما تبدأ:
- تغيير الدومين: كل اللينكات بتتغير، والإشارات لازم تنتقل من دومين لدومين، وبتستخدم أداة Change of Address في Search Console.
- التحويل من HTTP إلى HTTPS أو من non-www إلى www: كل اللينكات بتتغير بشكل ميكانيكي، فالتحويل سهل، بس سهل برضه إنك تغلط في تفاصيل صغيرة زي الكانونيكال والسايت ماب.
- تغيير هيكل اللينكات على نفس الدومين: شكل جديد للينكات، أو تصنيفات جديدة، أو إضافة فولدر للغة أو حذفه. لينكات كتير بتتغير بشكل مش ميكانيكي ومحتاجة جدول مطابقة حقيقي.
- تغيير المنصة: زي موقع على بيج بيلدر بيتعاد بناؤه بكود مخصص. اللينكات ممكن تفضل زي ما هي، لكن القوالب والعناوين واللينكات الداخلية والبيانات المنظمة وطريقة العرض والسرعة كلها بتتغير.
- إعادة تصميم من غير تغيير لينكات: أقل خطورة، بس القوالب والمحتوى ممكن يحركوا الترتيب برضه.
نصيحة جوجل واضحة: غير حاجة واحدة في المرة. لو تقدر تسيب اللينكات زي ما هي وأنت بتغير المنصة، اعمل كده الأول. ولو محتاج تغير الدومين وتعمل تصميم جديد، فرق بينهم بوقت كفاية علشان تعرف أنهي تغيير سبب أي حركة في الترتيب.
المرحلة الأولى: سجل الوضع الحالي قبل ما تلمس أي حاجة
مش هتقدر تثبت إن النقل نجح، ولا تعرف ليه فشل، من غير سجل لشكل الموقع القديم. خد اللقطة دي قبل أول تغيير، وخزنها في مكان يفضل موجود بعد المشروع.
جرد اللينكات
اعمل قائمة رئيسية واحدة بكل لينك موجود على الموقع القديم. مصدر واحد عمره ما بيكون كامل، فاجمع من أكتر من مصدر:
- ملفات XML sitemap، بما فيها سايت ماب الصور واللغات.
- زحف كامل على الموقع الشغال بأداة زحف، بيمشي ورا اللينكات الداخلية ويسجل كود الاستجابة والكانونيكال والعنوان وH1 وmeta robots وhreflang وعدد الكلمات.
- بيانات الأداء من Search Console متصدرة حسب الصفحة، لأطول فترة متاحة، لأن الصفحات اللي بتجيب ظهور ومش متلينكة داخليا مش هتظهر في الزحف.
- لوجات السيرفر، وهي بتوريك كل لينك بيطلبه جوجل بوت والزوار فعلا، بما فيها اللينكات القديمة اللي عليها لينكات خارجية.
- قاعدة بيانات الـ CMS: المقالات والصفحات والأنواع المخصصة وصفحات التصنيفات وصفحات المرفقات وصفحات الكتاب.
- بيانات الباك لينك من تقرير اللينكات في Search Console وأي أداة تانية بتستخدمها، علشان تعرف أنهي لينكات عليها روابط خارجية.
ضيف الصور وملفات PDF والملفات القابلة للتحميل. توثيق جوجل بيذكر الصور والفيديو وملفات JavaScript وCSS ضمن الحاجات اللي لازم تتعمل لها مطابقة، لأن زيارات بحث الصور وطريقة عرض الصفحة بيعتمدوا عليها.
سجل الأداء
صدر الأرقام دي مع تواريخها، علشان تقارن بيها بعد الإطلاق:
- النقرات والظهور ومتوسط الترتيب ونسبة النقر لكل صفحة ولكل كلمة بحث من Search Console.
- الزيارات العضوية والتحويلات من التحليلات، بما فيها الأحداث المهمة: إرسال نموذج استفسار، تأكيد حجز، ضغطة واتساب، مكالمة.
- حالة الفهرسة: كام صفحة مفهرسة، وأنهي صفحات مستبعدة وليه.
- بيانات Core Web Vitals الميدانية من Search Console، ونتائج معملية لأهم عشرة قوالب.
- ترتيب من 30 لـ 50 كلمة مهمة تجاريا، متتابع حسب الدولة واللغة.
رتب قائمة اللينكات حسب القيمة: نقرات عضوية وتحويلات وباك لينك. أهم 5 لـ 10 في المية من اللينكات غالبا بتشيل أغلب القيمة. دي بتاخد اهتمام فردي في خريطة التحويل وفي الفحص بعد الإطلاق.
المرحلة التانية: خريطة التحويلات
خريطة التحويلات هي أهم تسليم في أي نقل بتتغير فيه اللينكات. هي جدول فيه صف لكل لينك قديم ووجهته الجديدة، ومبني على قواعد يقدر المطور ينفذها ويقدر المختبر يراجعها.
قواعد المطابقة اللي بتحمي الترتيب
- واحد لواحد كأساس. كل لينك قديم يتحول للينك الجديد اللي بيقدم نفس المحتوى. التطابق معناه نفس نية البحث، مش نفس الكلمة في الـ slug.
- الصفحات المدمجة تتحول للصفحة المدمجة. لو تلات مقالات ضعيفة بقوا دليل واحد قوي، التلاتة يتحولوا للدليل.
- ماتحولش كل حاجة للصفحة الرئيسية. دليل جوجل بيحذر من إرسال لينكات غير مرتبطة لصفحة واحدة. التحويل الجماعي للرئيسية بيتعامل معاه في حالات كتير كـ soft 404 وبيضيع صلة الصفحة الأصلية.
- المحتوى الملغي يرجع 404 أو 410. لو الصفحة ملهاش بديل ولا قيمة، سيبها تروح بشكل نضيف بدل ما تحولها لحاجة مش مناسبة. ولو عليها باك لينك، دور الأول على بديل حقيقي.
- حول مباشرة للوجهة النهائية. السلاسل زي قديم ثم وسيط ثم نهائي بتضيع ميزانية الزحف وبتزود الوقت. دليل جوجل بيقول لو فيه سلسلة مش هتتجنبها خليها قصيرة، ويفضل مش أكتر من 3 خطوات ودايما أقل من 5. الهدف الصح صفر خطوات زيادة.
- استخدم تحويلات دائمة من السيرفر. كود 301 أو 308 بيقول لمحركات البحث إن النقل دايم. تحويلات JavaScript أو meta refresh تبقى آخر حل.
قواعد بالنمط ولا جدول مطابقة؟
لو التغيير ميكانيكي، زي نقل من /blog/2024/05/post-name/ إلى /post-name/، اكتب قاعدة واحدة بـ regular expression واختبرها على القائمة كلها. ولو التغيير تحريري، استخدم جدول مطابقة بتقراه طبقة التحويل وقت الطلب. ولو عندك عشرات الآلاف من اللينكات، ماتحطش آلاف الأسطر في ملف .htaccess لأنه بيتقرا مع كل طلب. الأحسن خريطة على مستوى السيرفر (Nginx map أو Apache RewriteMap بملف مفهرس) أو جدول تحويلات في الأبلكيشن بكاش، وخلي القواعد في نظام إصدارات.
تفاصيل بتكسر الخريطة من غير ما تحس
- الشرطة في الآخر وحالة الحروف. اتفق على الشكل الأساسي وحول الباقي ليه في خطوة واحدة.
- الباراميترات. قرر أنهي باراميترات تفضل (الترقيم، والفلاتر اللي بتعمل صفحات قابلة للفهرسة) وأنهي تتشال. باراميترات التتبع ماتعملش لينكات جديدة.
- فولدرات اللغات. في الموقع بلغتين، النسخة العربي والإنجليزي كل واحدة ليها خريطتها، والمطابقة لازم تفضل لغة للغتها. لينك عربي ماينفعش يتحول لصفحة إنجليزي. والـ slug العربي المشفر بـ percent-encoding لازم يتقارن بصيغة موحدة، وإلا القواعد مش هتطابق اللي المتصفح بيبعته. في مقال سيو المواقع السياحية متعددة اللغات شرح أكتر لموضوع hreflang.
- الترقيم والأرشيف. أرشيف التصنيفات والوسوم والتواريخ كتير بيجيب لينكات. اعمل لها مطابقة أو قرر إلغاءها عن قصد.
- الميديا. لو مسار الرفع اتغير، اعمل مطابقة للينكات الصور كمان، وإلا ظهورك في بحث الصور هيرجع من الصفر.
- التحويلات القديمة. لو الموقع القديم فيه تحويلات أصلا، اعمل لها تسطيح: أقدم لينك لازم يشاور على اللينك النهائي الجديد مباشرة.
المرحلة التالتة: ابني واختبر على بيئة تجريبية
الموقع الجديد بيتبني في بيئة خاصة، والبيئة دي ماينفعش تتفهرس أبدا. المشكلة المعروفة: الموقع التجريبي متقفل بـ noindex أو بقاعدة disallow في robots.txt، والموقع يتنشر، والقفل يتنشر معاه. حط إزالة القفل ده كخطوة صريحة في الإطلاق، وضيف اختبار يفشل لو القفل لسه موجود.
تطابق الصفحات
قارن كل صفحة قديمة مهمة بنسختها الجديدة. إعادة البناء كتير بتغير حاجات محدش كان ناوي يغيرها:
- عناوين الصفحات والوصف وH1 وهيكل العناوين.
- نص المحتوى، خصوصا النص اللي التصميم الجديد بيخبيه ورا تابات أو سلايدرز أو سكريبتات بتتحمل متأخر.
- اللينكات الداخلية. القائمة والفوتر واللينكات جوه المحتوى لازم تشاور على اللينكات الجديدة النهائية، مش على لينكات بتتحول.
- الكانونيكال: كل صفحة محتاجة كانونيكال بيشاور على نفسها بلينكها النهائي الجديد.
- hreflang: محدثة للينكات الجديدة، ومتبادلة، وفيها إشارة للصفحة نفسها.
- البيانات المنظمة: نفس الأنواع ونفس القيم الصحيحة، واللينكات متحدثة.
- النص البديل وأسماء ملفات الصور.
- robots meta وهيدرز X-Robots-Tag.
الفحوصات التقنية
- العرض: استخدم أداة فحص اللينك URL Inspection أو متصفح بدون واجهة علشان تتأكد إن المحتوى المهم موجود في الـ HTML بعد العرض.
- أكواد الاستجابة: شغل كل قائمة اللينكات القديمة على قواعد التحويل في البيئة التجريبية بسكريبت، وتأكد من الكود والوجهة المتوقعين لكل صف. التقرير يطلع فروقات، مش إحساس.
- السرعة: قارن قوالب Core Web Vitals بالأرقام القديمة. نقل بيخلي الموقع أبطأ بيضيع جزء من اللي كنت عايزه. شوف ملاحظاتنا عن تحسين سرعة الموقع للتفاصيل الهندسية.
- قدرة السيرفر: دليل جوجل بيطلب منك تتأكد إن السيرفر الجديد يستحمل زحف أثقل من جوجل بوت بعد النقل، لأن الزواحف بتزور لينكات كتير في وقت قصير. اختبر طبقة التحويل والسيرفر الأصلي الجديد تحت الحمل ده.
- الأمان وHTTPS: شهادة سليمة على كل نسخة من الهوست هتحولها، وفعل HSTS بس لما تتأكد، ومفيش mixed content.
- النماذج والدفع والتتبع: ابعت استفسار تجريبي حقيقي، وكمل حجز تجريبي، وتأكد إن أحداث التحليلات بتشتغل مرة واحدة بس.
المرحلة الرابعة: Search Console والتحليلات والسايت ماب
خلص شغل الحسابات قبل يوم الإطلاق علشان اليوم ده يبقى تنفيذ بس.
- وثق كل نسخة من الموقعين القديم والجديد: HTTP وHTTPS وwww وnon-www. وخاصية الدومين بتغطيهم في توثيق واحد. وتأكد إن طريقة التوثيق هتفضل شغالة بعد النقل: ملف أو تاج على السيرفر القديم هيختفي مع السيرفر.
- لو انتقلت لدومين جديد، راجع تاريخه علشان تتأكد إن مفيش إجراءات يدوية أو طلبات إزالة لينكات باقية من مالك سابق.
- جهز XML sitemap جديد فيه اللينكات النهائية القابلة للفهرسة بس، بتواريخ تعديل صحيحة.
- سيب السايت ماب القديم متاح فترة بعد الإطلاق علشان جوجل يكتشف التحويلات بسرعة. تحذيرات إن السايت ماب القديم فيه لينكات بتتحول طبيعية في الفترة دي.
- جهز التحليلات علشان تقدر تقارن الدومين القديم بالجديد، وحط ملاحظة بتاريخ الإطلاق.
- لو عندك ملف disavow ارفعه تاني على الموقع الجديد، وطابق إعدادات الزحف لو ليها لزوم.
المرحلة الخامسة: يوم الإطلاق
اختار وقت قليل الزيارات، وماتطلقش في يوم مفيش فيه حد يقدر يتصرف. جوجل بيوصي بجدولة النقل في فترة الهبوط المؤقت فيها أقل ضرر. لفندق أو مركز غوص في الغردقة ده معناه تتجنب أسابيع ذروة الحجز، ولمصدر B2B تتجنب آخر الشهر وقت عروض الأسعار.
ترتيب الإطلاق
- خد نسخة احتياطية كاملة من الموقع القديم وقاعدة البيانات، وتأكد إنك تقدر ترجعها.
- انشر الموقع الجديد وشيل كل أقفال البيئة التجريبية: تاجات noindex وهيدرز X-Robots-Tag وقواعد disallow في robots.txt وحماية الباسورد.
- فعل قواعد التحويل.
- شغل سكريبت اختبار التحويلات على الموقع الحقيقي. كل الصفوف لازم تنجح.
- افحص أهم 50 لينك بإيدك في المتصفح وفي أداة URL Inspection، منهم صفحة عربي وصفحة إنجليزي، على الموبايل والديسكتوب.
- لو غيرت الدومين، ابعت Change of Address في Search Console لكل نسخة موثقة من الموقع القديم. الأداة دي للدومين أو الساب دومين بس، مش لتغيير المسارات أو المنصة.
- ابعت السايت ماب الجديد.
- حدث كل حاجة تحت سيطرتك بتشاور على اللينكات القديمة: حسابات السوشيال ولينك الموقع في ملف النشاط على جوجل والحملات الإعلانية وتوقيع الإيميل والأدلة وموقع الشركاء.
- تأكد في التحليلات إن الزيارات وأحداث التحويل بتتسجل على الموقع الجديد.
المرحلة السادسة: أول 30 يوم
توقع تذبذب. جوجل بيقول إن نقل الموقع ممكن ياخد كام أسبوع للمواقع الصغيرة والمتوسطة وأكتر للكبيرة، لأن كل لينك قديم وجديد لازم يتزحف عليه مرة واحدة على الأقل والعملية بتمشي لينك لينك. حركة مؤقتة في الترتيب مش معناها فشل. اللي معناه فشل هو النمط، والطريقة اللي تمسك بيها النمط هي روتين متابعة بفحوصات ثابتة.
يوميا في أول أسبوعين
- لوجات السيرفر: طلبات جوجل بوت حسب كود الاستجابة. زيادة 404 معناها لينكات ناقصة من الخريطة. زيادة أخطاء 5xx معناها مشكلة قدرة. موجة 301 بعدها 200 على اللينكات الجديدة هي النمط السليم.
- Search Console: تقرير السايت ماب وتقرير فهرسة الصفحات. اللينكات الجديدة المفروض عددها المفهرس يزيد والقديمة تقل.
- أخطاء الزحف من أداة الزحف بتاعتك: ازحف على الموقع الجديد كل أسبوع وقارن بالأساس: عناوين ناقصة، كانونيكال غلط، noindex مش متوقع.
- التحليلات: صفحات الهبوط العضوية والتحويلات مقارنة بفترة الأساس، مع مراعاة الموسم.
أسبوعيا لحد يوم 30
- قارن النقرات والظهور لأهم 5 لـ 10 في المية من اللينكات بالأساس.
- افصل كلمات البراند عن غير البراند. كلمات البراند بترجع الأول، وفجوة في غير البراند على نفس الصفحات معناها تغيير في المحتوى أو الصلة.
- راجع قائمة الكلمات المتتبعة حسب الدولة واللغة.
- اطلب الإصلاحات بالترتيب: تحويلات مهمة مكسورة، بعدها كانونيكال غلط، بعدها محتوى ناقص، بعدها الباقي.
تشخيص النزول
لو الزيارات نزلت ومرجعتش، امشي ورا الأدلة بالترتيب ده. أول حاجة الفهرسة: هل اللينكات الجديدة مفهرسة، واللينكات القديمة بتختفي زي المتوقع؟ تاني حاجة سلامة التحويلات: هل هي خطوة واحدة وبكود 301 ولصفحة صح؟ تالت حاجة تطابق الصفحات: هل العناوين أو المحتوى اتغيروا بشكل كبير؟ رابع حاجة العرض: هل المحتوى ظاهر في الـ HTML بعد العرض؟ خامس حاجة السرعة وأخطاء السيرفر. سادس حاجة اللينكات: هل اللينكات الخارجية على القديم اتجمعت عن طريق التحويلات، واللينكات الداخلية اتحدثت؟ وبعد كل ده بس دور على تفسيرات الخوارزميات، لأن الأسباب الأولى أكتر بكتير وبتتصلح.
سيب التحويلات شغالة فترة كفاية
دليل جوجل بيقول سيب التحويلات شغالة عادة سنة على الأقل. عمليا، سيبها طول ما اللينكات القديمة عليها باك لينك أو متحفظة في بوكمارك. التحويلات رخيصة تفضل وغالية لو اتشالت: شيلها بدري بيحول كل لينك خارجي قديم لـ 404. وثق جدول التحويلات كجزء من التوثيق الدائم للموقع، وتأكد إن أي مطور بعد كده مايقدرش يشيل القواعد من غير ما يشوف هي بتحمي إيه. ولو القواعد جوه إضافة، احتفظ بنسخة مصدرة من الجدول برا الموقع، علشان تغيير إضافة أو نقل استضافة مايمسحهاش من غير ما حد ياخد باله.
حالات خاصة للمواقع المصرية ومتعددة اللغات

- الانتقال بين .com و.com.eg: الدومين بكود الدولة إشارة جغرافية. لو سوقك مصر، اتأكد إن استهداف الدومين الجديد لسه مناسب لجمهورك، وافتكر إن الزوار الدوليين ممكن يثقوا في .com بشكل مختلف. قرر بناء على بيانات الجمهور، مش على الذوق.
- مبدلات اللغة: إضافات اللغات ممكن تعمل لينكات مكررة أو متعارضة وقت النقل، زي اللغة الأساسية تظهر بفولدر وبدون فولدر. اختبر كل التركيبات، وتأكد إن أزواج hreflang لسه متبادلة بعد النقل.
- اللينكات العربي: المتصفح بيعرض الـ slug العربي، لكن السيرفر واللوجات بيشوفوا الشكل المشفر. اختبر التحويلات بالشكل المشفر، وقرر هل الصفحات العربي الجديدة هتستخدم slug عربي ولا لاتيني قصير. تغيير سياسة الـ slug وقت النقل بيعمل تحويلات ملهاش لازم.
- تغيير الاستضافة: لو النقل هيشمل السيرفر الأصلي كمان، اقرا مقارنتنا عن الاستضافة داخل مصر ولا بره قبل ما تختار المكان، وقلل TTL للدومين قبلها بكام يوم علشان التبديل يبقى سريع.
- تغيير المنصة: الانتقال من موقع على بيج بيلدر لكود مخصص بيغير القوالب وطريقة العرض. دليلنا ووردبريس ولا لارافيل بيشرح الاختيارات المعمارية، وخطة النقل لازم تتعامل مع القوالب الجديدة كتمرين تطابق محتوى، نوع صفحة بنوع صفحة.
قائمة الموافقة قبل الإطلاق
اعتبر القائمة دي بوابة. لو أي بند مش متأكد منه بدليل، الإطلاق يستنى.
- جرد اللينكات كامل ومجمع من السايت ماب والزحف وSearch Console واللوجات والـ CMS والباك لينك.
- أرقام الأساس متصدرة ومؤرخة.
- كل لينك قديم ليه وجهة مطابقة أو 404 أو 410 مقصودين.
- سكريبت اختبار التحويلات بينجح على البيئة التجريبية بصفر فشل وصفر سلاسل.
- الكانونيكال وhreflang والبيانات المنظمة واللينكات الداخلية بتشاور على اللينكات الجديدة النهائية.
- مفيش noindex تجريبي ولا قفل robots.txt ولا حماية باسورد فاضل في نسخة الإطلاق.
- السايت ماب الجديد فيه لينكات نهائية قابلة للفهرسة بس.
- موقعي Search Console القديم والجديد موثقين، والتوثيق هيفضل بعد النقل.
- النماذج والدفع والحجز وأحداث التحليلات عدت اختبار من أول لآخر.
- خطة الرجوع محددة: مين بيقرر، في أد إيه، وإزاي الموقع القديم بيرجع.
- فيه حد متكلف بروتين المتابعة لكل يوم من أول 30 يوم.
مين يدير النقل؟
نقل الموقع بيعدي على حدود بين السيو والتطوير والاستضافة، وهنا أغلب الفشل: متخصص السيو يكتب خريطة تحويل والمطور ينفذها بشكل مختلف، وفريق الاستضافة يعمل كاش لحاجة غلط. لازم يبقى فيه مسؤول واحد ماسك الخطة، وخريطة التحويل وسكريبت الاختبار وروتين المتابعة في مستند واحد التلات تخصصات يمضوا عليه. فرق خدمة السيو والاستضافة المدارة عندنا بتخطط النقل بحيث يتكتب سكريبت اختبار التحويلات قبل أول قاعدة تحويل، لأن القاعدة اللي ماتقدرش تختبرها أوتوماتيك قاعدة ماتقدرش تثق فيها، والنقل آخر مكان تكتشف فيه ده.