ترحيل المواقع

الخلاصة — ترحيل الموقع هو أي تغيير كبير في موقعك قد ينقل عناوين URL أو يغيّر طريقة قراءة Google لها: نطاق جديد، أو انتقال إلى HTTPS، أو منصة جديدة، أو إعادة ترتيب للمجلدات، أو حتى إعادة تصميم. وحماية الزيارات تتبع القاعدة نفسها كل مرة: أعد توجيه كل صفحة قديمة برمز 301 إلى أقرب صفحة جديدة مكافئة، وأبقِ عمليات إعادة التوجيه مدة طويلة. الانخفاض المؤقت في الزيارات طبيعي؛ أما إن لم تتعافَ، فثمة عطل وقع.

ما ترحيل الموقع؟

قد تبدو كلمة «الترحيل» درامية، وهي كذلك أحيانًا. لكنها تعني ببساطة تغييرًا مهمًا في الموقع يمكن أن يؤثر في كيفية عثور محركات البحث على صفحاته وقراءتها وترتيبها. فالانتقال إلى نطاق جديد ترحيل، والتحول من http:// إلى https:// ترحيل، ونقل المدونة من blog.example.com إلى example.com/blog/ ترحيل. وحتى إعادة التصميم التي تُبقي كل عنوان URL كما هو تُعد ترحيلًا، لأن المحتوى والقوالب التي ترتبها Google تتغير.

وجُمعت هذه التغييرات معًا لأنها تشترك في المخاطر نفسها وفي خطة العمل نفسها.

القاعدة الأهم على الإطلاق

عندما يتغير عنوان URL، عليك إخبار المتصفحات ومحركات البحث بمكان انتقال الصفحة. ويتم ذلك عبر إعادة توجيه، وتحديدًا إعادة توجيه 301 (دائمة)، التي تقول إن الصفحة انتقلت إلى هذا المكان نهائيًا. عمليات إعادة التوجيه هي التي تنقل ترتيبك فعليًا من العناوين القديمة إلى الجديدة. وتقول Google إن 301 وغيرها من عمليات إعادة التوجيه الدائمة لا تسبب فقدان PageRank.

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

أخطاء شائعة

• «عمليات إعادة التوجيه تفقدني قيمة الروابط». لا تفعل. عمليات إعادة التوجيه الدائمة لا تخصم PageRank؛ وقد انتهت صلاحية هذه الخرافة منذ سنوات.
• «أداة Change of Address تنقل موقعي بدلًا مني». لا تفعل. أداة Google Search Console هذه لا تتجاوز إخبار Google بأنك انتقلت إلى نطاق جديد؛ أما إعادة التوجيه فتؤدي العمل الحقيقي. كما أنها مخصصة لنقل النطاق بأكمله، لا للتحول إلى HTTPS أو إعادة ترتيب المجلدات.
• «انخفضت زياراتي، إذًا فشل الترحيل». ليس غالبًا. التذبذب المؤقت بينما تعيد Google فهم كل شيء أمر طبيعي؛ امنحه بضعة أسابيع. Evidence for this claim Google says to expect temporary ranking fluctuations during a site move; most pages on a medium-sized site can take a few weeks to move in Google's index, and larger sites take longer. Scope: Google Search's general expectations for moves with URL changes; actual timing varies by site and does not promise recovery by a fixed date. Confidence: high · Verified: 2026-07-14 Google Search Central: Site move with URL changes
• «يمكنني إزالة عمليات إعادة التوجيه بعد بضعة أشهر». أبقها مدة أطول بكثير، ويفضل سنوات، وعمليًا إلى الأبد متى أمكن.

غيّر شيئًا واحدًا في كل مرة

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

هل تريد العملية كاملة، بمراحلها السبع واستراتيجية إعادة التوجيه وقائمة مخصصة لكل نوع ترحيل؟ انتقل إلى تبويب المتقدم.

الخلاصة — مخاطر الترحيل = حجم التغيير × مقدار ما تنفذه دفعة واحدة. عمليات 301/308 هي العمود الفقري؛ فهي تنقل الترتيب ولا تفقد PageRank، وكل ما عداها، مثل Change of Address وملفات sitemap والروابط الداخلية والروابط الأساسية، إشارات مساندة. اربط القديم بالجديد بنسبة 1:1، ولا تحوّل عناوين كثيرة إلى الرئيسية (404 ناعم)، وتجنب السلاسل، وأبقِ عمليات إعادة التوجيه أطول بكثير من عبارة «12 شهرًا». توقّع تذبذبًا مؤقتًا ثم تعافيًا؛ والانخفاض الدائم يعني غالبًا أن شيئًا تعطل، مثل بقاء حظر بيئة الاختبار، أو حذف hreflang/canonical، أو وسم noindex شارد، أو وجهات إعادة توجيه خاطئة. فيما يلي العملية العامة ذات المراحل السبع، ثم خصوصيات كل واحد من أنواع الترحيل السبعة.

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

ما الترحيل فعليًا؟ وما أنواعه السبعة؟

ترحيل الموقع هو أي تغيير مهم في بنية عناوين URL أو النطاق أو المنصة أو البروتوكول أو الاستضافة، وقد يؤثر في زحف محركات البحث وفهرستها وترتيبها. ويشمل المصطلح كل شيء من تحويل HTTPS بسطر واحد إلى إعادة تسمية كاملة تنقل مئات آلاف العناوين إلى نطاق جديد عبر نظام CMS جديد.

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

الأرقام هي ترتيب الأقسام في الشرح التفصيلي أدناه، أما الجدول فمرتب حسب الخطر لتعرف موضع حالتك. الخطر = حجم ما تغيّره × مقدار ما تغيّره دفعة واحدة. إعادة تصميم بالعناوين نفسها منخفضة الخطر، بينما يجمع تغيير النطاق وإعادة هيكلة URL وتغيير المنصة معًا ثلاثة أنواع عالية الخطر؛ ونصيحة Google نفسها هي تغيير شيء واحد في كل مرة.

عملية الترحيل العامة

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

المرحلة 1 — التخطيط

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

المرحلة 2 — القياس المرجعي وزحف الموقع القديم

لا يمكنك ضمان جودة الترحيل من دون صورة «قبل». التقطها والموقع القديم ما زال مباشرًا:

• ازحف إلى الموقع القديم بالكامل عبر Screaming Frog أو Ahrefs Site Audit أو ما يعادلهما، واحفظ النتيجة لتكون خط الأساس للمقارنة بعد الإطلاق.
• التقط لكل URL: رمز الحالة، والعنوان، والوصف الوصفي، وcanonical، وhreflang، وبنية العناوين، وبنية الروابط الداخلية، وCore Web Vitals.
• التقط ترتيب الكلمات لكل الصفحات المهمة قبل الإطلاق.
• صدّر معايير الزيارات من أداء Search Console لآخر 3/6/12 شهرًا ومن GA4 على مستوى الصفحة/الجلسة.
• صدّر أهم الصفحات حسب الروابط الخلفية من Ahrefs وتقرير Links في GSC؛ يجب أن تُعاد توجيهها بدقة لأنها تحمل قيمة الروابط.
• اجمع كل إعادة توجيه قائمة من CMS وCDN وملف .htaccess أو إعداد الخادم وتقرير Page with redirect في Search Console والتحليلات. إغفال مصدر واحد ينشئ سلاسل بعد الإطلاق.
• راجع المشكلات القديمة قبل نقلها؛ فالنطاق أو CMS الجديد ليس مبررًا لاستيراد أخطاء canonical أو تضخم الفهرس أو حظر الزحف.

المرحلة 3 — تعيين عناوين URL

أنشئ جدولًا بنسبة واحد إلى واحد: كل عنوان URL قديم ← أكثر عنوان جديد صلة به. بلا استثناء؛ يجب اتخاذ قرار لكل عنوان.

• صفحات محذوفة لها بديل قريب: أعد توجيهها إلى أقرب صفحة مباشرة ذات صلة موضوعية. Google صريحة: لا تعِد توجيه عناوين قديمة كثيرة إلى وجهة واحدة غير ذات صلة مثل الرئيسية. Evidence for this claim Google advises against redirecting many old URLs to one irrelevant destination such as the home page and says that can be treated as a soft 404. Scope: Google Search guidance for site moves with changed URLs; relevant replacements remain appropriate. Confidence: high · Verified: 2026-07-14 Google Search Central: Site move with URL changes
• صفحات بلا أي بديل: أرجع 410 (أزيلت) أو 404 صحيحًا، ولا تحوّلها إلى الرئيسية؛ فهذا يُعامل كـ404 ناعم.
• تتبع كل عنوان هو أهم جزء، لتملك خريطة واضحة لما كان عليه وما ينبغي أن يصبحه. هذه الخريطة هي الترحيل.

المرحلة 4 — استراتيجية إعادة التوجيه

هذا هو العمود الفقري للمشروع كله.

• استخدم 301 (نُقل دائمًا) أو 308 للنقل الدائم. توصي Google بعمليات إعادة توجيه دائمة على الخادم مثل 301 و308.
• تمرر 301 قيمة PageRank، وانتهى. تقول وثائق Google إن العمليات الدائمة لا تسبب خسارة PageRank، وأكد Gary Illyes منذ سنوات أن 30x لم تعد تفقدها. أي دليل يقول بعكس ذلك قديم. Evidence for this claim Google says 301 and other permanent redirects do not cause a loss in PageRank. Scope: Google Search handling of permanent redirects during site moves; this does not guarantee unchanged rankings after a migration. Confidence: high · Verified: 2026-07-14 Google Search Central: Site move with URL changes
• تجنب سلاسل إعادة التوجيه. اربط القديم بالجديد مباشرة. تقول Google اجعل السلسلة قصيرة، ويفضل ألا تتجاوز 3 وأقل من 5. يتبع Googlebot نحو 10 قفزات، فلا تكون السلاسل القصيرة قاتلة، لكن كل قفزة فرصة للعطل وتأخير لتوحيد الإشارات. ومن المصادر الخفية الشائعة عدم اتساق الشرطة المائلة الأخيرة (/page مقابل /page/)؛ اختر صيغة canonical واحدة وحوّل الأخرى.
• أعد توجيه الأصول أيضًا مثل الصور وPDF والملفات غير HTML، لا الصفحات فقط.
• استخدم الخادم فقط. إعادة التوجيه بجافاسكربت حل أخير؛ قد لا تعالجها Google إن فشل العرض.
• لا تخلط المؤقت بالدائم. لا تخبر 302/307 مسار الفهرسة بأن الوجهة يجب أن تكون canonical؛ فيبقى القديم مفهرسًا وتظل الإشارات غالبًا مكانها. استخدمها للحالات المؤقتة فعلًا.
• أبقِ العمليات أطول بكثير من «عام واحد». حد Google الأدنى «سنة على الأقل»، لكن Illyes أوضح أن نحو 12 شهرًا تفيد Google أساسًا، فيما يستفيد المستخدمون من إبقائها عمليًا إلى الأبد. ويميل Bing إلى 1–2 سنة على الأقل. قاعدتي: أبقها ما دامت العناوين القديمة تجلب أي زيارات أو روابط، أي غالبًا بلا أجل. Evidence for this claim Google recommends keeping site-move redirects as long as possible, generally for at least one year. Scope: Google Search's minimum site-move guidance; continuing user traffic or links can justify retaining redirects longer. Confidence: high · Verified: 2026-07-14 Google Search Central: Site move with URL changes

المرحلة 5 — بيئة الاختبار وفحوص ما قبل الإطلاق

• امنع فهرسة بيئة الاختبار عبر noindex و/أو Disallow في robots.txt على مضيف الاختبار. قيّد الوصول لتجنب الفهرسة من الأصل، وسجّل هذا الحظر للمرحلة 6 لأنه يجب أن يُزال عند الإطلاق.
• استخدم اسم مضيف مؤقتًا مثل beta.example.com للاختبار العام.
• اختبر كل إعادة توجيه من القديم إلى الجديد. كثيرًا ما يحوّل الناس إلى عناوين خاطئة غير موجودة؛ ازحف إلى قائمة العناوين القديمة كاملة على بيئة الاختبار وتأكد أن كل عنوان يصل إلى الصفحة المباشرة المقصودة بقفزة واحدة.
• قارن زحف الاختبار بخط أساس المرحلة 2: العناوين والأوصاف وcanonical وhreflang والبيانات المنظمة وmeta robots والروابط الداخلية والسرعة.
• تأكد أن canonical يشير إلى الموقع المباشر لا إلى عناوين الاختبار.
• تحقق من عمل التحليلات مثل GA4 وتوثيق GSC ومدير الوسوم، واختبر النماذج والدفع ومسارات التحويل.
• تأكد أن جدار الحماية أو حماية DoS لا تحجب Googlebot، وأنه يصل إلى DNS والمضيف.

المرحلة 6 — الإطلاق

• أزل كل حظر للزحف فورًا، بما فيه noindex وقواعد robots.txt الخاصة ببيئة البناء. أشهر كارثة ترحيل هي نشر حظر الاختبار على الموقع المباشر.
• فعّل جميع عمليات 301 معًا.
• حدّث ملف sitemap XML الحالي للإنتاج وأعد إرساله بحيث يحتوي عناوين canonical الجديدة فقط. إذا أفاد ملف منفصل للعناوين القديمة في اكتشاف التحويلات أو المراقبة، فأرسله منفصلًا ومؤقتًا بوضوح؛ لا تخلط القائمتين، واحذفه عندما ينتهي نفعه. راجع إرشادات نقل الموقع من Google.
• افحص عينة من التحويلات بأداة URL Inspection في GSC.
• أرسل Change of Address للنقل على مستوى النطاق فقط (النوع 1).
• لـBing أرسل عبر IndexNow، وهي الآلية الحالية. أداة Site Move القديمة أُهملت قرابة 2021؛ لا تتبع أدلة ما زالت توصي بها. يتيح IndexNow إرسال كل العناوين المنقولة دفعة واحدة.
• وفّر سعة خادم كافية، لأن Google ستزحف إلى الموقع الجديد بكثافة أعلى بعد النقل مباشرة.

المرحلة 7 — المراقبة بعد الإطلاق

• توقع تذبذبًا مؤقتًا. تقول Google إن ترتيب الموقع يتذبذب أثناء النقل؛ والانخفاض لا يثبت الفشل. وأشار Martin Splitt إلى أن نسخ بنية URL والمحتوى بالكامل إلى نطاق جديد قد لا يسبب انخفاضًا أصلًا. Evidence for this claim Google says to expect temporary ranking fluctuations during a site move; most pages on a medium-sized site can take a few weeks to move in Google's index, and larger sites take longer. Scope: Google Search's general expectations for moves with URL changes; actual timing varies by site and does not promise recovery by a fixed date. Confidence: high · Verified: 2026-07-14 Google Search Central: Site move with URL changes
• اعرف الجدول الزمني. تقول Google إن نقل معظم صفحات موقع متوسط في فهرسها قد يستغرق بضعة أسابيع، والمواقع الأكبر أطول. والاستقرار الكامل غالبًا بين شهرين وثلاثة، وقد يستغرق عامًا للمواقع الضخمة.
• راقب يوميًا: فهرسة الصفحات والأداء حسب الصفحة وإحصاءات الزحف والإجراءات اليدوية في GSC، والزيارات العضوية في GA4، وترتيب الصفحات المهمة، وسجلات الخادم لنشاط Googlebot.
• أعد الزحف إلى قائمة العناوين القديمة كلها، لا إلى عينة، وتأكد من أن كل عنوان يعطي 301 ويصل للوجهة الصحيحة. وتقول Google إنها ترى مرارًا تحويلات إلى عناوين خاطئة غير موجودة.
• حدّث الروابط الداخلية لتشير إلى العناوين الجديدة مباشرة بدل المرور بالتحويل.
• اطلب من أصحاب أهم الروابط الخارجية تحديثها، خصوصًا الصفحات الأعلى قيمة.
• احذف ملف sitemap المؤقت للعناوين القديمة عندما لا يعود يقدم فائدة في الاكتشاف أو القياس، مع إبقاء ملف الإنتاج مقتصرًا على العناوين الجديدة.
• إذا انخفضت الزيارات ولم تتعافَ: افحص أولًا حظر الاختبار الباقي، وhreflang المحذوف، وnoindex الشارد، وcanonical المعطل، والتحويلات الخاطئة. التذبذب طبيعي؛ الانخفاض الدائم يعني أن شيئًا تعطل.
• استخدم معايير التراجع التي اتفقت عليها مسبقًا، لا الذعر في اليوم الأول.

هل نجحت إعادة التوجيه؟ قياس الأثر من دون خداع النفس

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

في كل نقطة، قارن فترة ما بعد التغيير بفترة مكافئة قبله واستبعد يوم التغيير. يجمع يوم الإطلاق حالتي القديم والجديد والنشر الجزئي وتغيرات الذاكرة المؤقتة وزيارات ضمان الجودة وانقطاعات التتبع؛ ونسبته لأي جانب يلوث المقارنة. ثبّت تعريفات المجموعة والمقياس، ولا تقسّم حسب العلامة/غير العلامة أو الجهاز أو البلد أو القالب أو نوع الترحيل إلا إذا كانت تلك التقسيمات في خطة القياس.

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

«لا تغيير» نتيجة صالحة. وظيفة إعادة التوجيه غالبًا حفظ الوصول والإشارات والتحويلات أثناء انتقال العناوين. وقد يكون ثبات الأداء مع استجابات سليمة بقفزة واحدة نجاحًا. سجّل ذلك بدل البحث عن قصة نمو لا تدعمها البيانات.

مكان Before/After Impact Checker المخطط له هنا في سير العمل؛ فعند إطلاقه يمكنه توحيد استبعاد يوم التغيير ومقارنات 7/14/30/90 يومًا. إلى ذلك الحين استخدم جدول بيانات أو طبقة تقارير واحفظ نطاقات التواريخ والمرشحات والمجموعة والملاحظات الدقيقة لكل نقطة.

أنواع الترحيل السبعة

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

النوع 1 — تغيير النطاق / إعادة تسمية العلامة

ما هو: نقل كل الصفحات من oldbrand.com إلى newbrand.com، أي نطاق وملكية GSC جديدان، ويفضل بلا تغيير متزامن في بنية URL.

الخطر: الأعلى. يتغير كل URL، وتحتاج الروابط الخارجية إلى تحديث، وينقسم سجل GSC بين ملكيتين.

المحاذير والخطوات الإلزامية:

• لا تجمع تغيير النطاق وإعادة التصميم وإعادة هيكلة URL. تحذر وثائق Change of Address من Google من أن جمع نقل النطاق مع إعادة تصميم المحتوى وبنية URL سيؤدي غالبًا إلى فقدان بعض الزيارات. انقل النطاق أولًا وأعد الهيكلة لاحقًا.
• تحقق من تاريخ النطاق الجديد قبل تسجيله. افحص archive.org؛ فقد يبدأ نطاق مسجل سابقًا وله تاريخ إجراءات يدوية علامتك الجديدة من موقع متأخر.
• لا تدع النطاق القديم ينتهي. جدده وأبق التحويلات؛ فإذا انقضى واستولى عليه غيرك ماتت التحويلات وقيمة الروابط.
• لا تسلسل عمليات نقل النطاق (A ← B ثم B ← C فورًا)، إذ لا يمكن تسلسل أداة Change of Address.

أداة Change of Address: ما تفعله وما لا تفعله. هنا يقع معظم الالتباس. تطلب الأداة من Google تكثيف زحف الموقع الجديد وفهرسته، وتنقل الإشارات، وتفضل canonical الخاصة به لمدة 180 يومًا. والمهم:

• تعمل لنقل نطاق أو نطاق فرعي من دون نطاق مسار، لا لنقل صفحات أو مجلدات منفردة داخل الموقع.
• يجب أن تكون مالكًا موثقًا لملكيات Search Console قديمة وجديدة مؤهلة. تؤهل ملكية Domain وكذلك ملكية URL-prefix جذرية، ولا تؤهل ملكية URL-prefix مقيدة بمسار. راجع متطلبات Change of Address وإرشادات أهلية الملكية من Google.
• هي عملية 1:1 صارمة، فلا تصلح للدمج أو النقل الجزئي.
• هي اختيارية لا إلزامية. إنها إشارة إضافية؛ إذا أعددت التحويلات جيدًا فستنجح من دونها. تؤدي 301 العمل الحقيقي، وتسرّع الأداة الرسالة وتوضحها فقط. ويوجد شرح مستقل لها ضمن مجموعة أدوات محركات البحث.

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

النوع 2 — HTTP ← HTTPS

ما هو: الانتقال من HTTP غير المشفر إلى HTTPS (TLS/SSL). يتغير كل عنوان من http:// إلى https://. كان HTTPS إشارة ترتيب خفيفة منذ 2014، واليوم يمثل البقاء على HTTP عيبًا فعليًا.

الخطر: منخفض–متوسط عند التنفيذ السليم، ومرتفع إذا ظهرت مشكلات الشهادة أو المحتوى المختلط.

المحاذير والخطوات الإلزامية:

• لا تستخدم Change of Address. تقول Google صراحةً استخدم إرشادات نقل الموقع بدلًا منها لنقل HTTP ← HTTPS.
• استخدم 301 لكل URL، لا قاعدة عامة ترمي الجميع إلى الصفحة الرئيسية. كلما أوضحت أن التغيير في البروتوكول فقط، كان الانتقال أسلس.
• أصلح المحتوى المختلط. أي صورة أو نص برمجي أو ورقة أنماط تبقى محملة عبر HTTP تثير تحذيرات وإشارات متعارضة. استخدم عناوين نسبية أو نسبية للبروتوكول؛ وسياسة Content Security Policy بقيمة upgrade-insecure-requests تنظف البقايا سريعًا.
• تفضل Google HTTPS تلقائيًا بوصفه canonical، إلا مع شهادة غير صالحة أو تبعيات غير آمنة أو تحويل راجع إلى HTTP أو إشارات متعارضة. فالشهادة الفاشلة قد تُبقي نسخة HTTP هي canonical.
• تعامل بحذر مع HSTS. يجبر المتصفح على HTTPS مدة محددة؛ وتفعيله قبل استقرار TLS يحوّل خطأ الشهادة إلى فشل كامل للزوار العائدين. أضفه بعد الاطمئنان، بدءًا من max-age منخفض ثم زد المدة.
• استخدم شهادة قوية (RSA‏ 2048 بت أو EC، واستهدف A/A+ في Qualys SSL)، وضع سمة Secure لملفات تعريف الارتباط.

النوع 3 — تغيير المنصة / نظام CMS

ما هو: الانتقال إلى CMS أو مكدس تقني جديد، مثل WordPress ← headless أو Magento ← Shopify. وغالبًا يجر معه تغييرات في URL والقوالب والروابط الداخلية والعرض.

الخطر: مرتفع، لأن أشياء متعددة تتغير معًا.

المحاذير والخطوات الإلزامية:

• توقع تغيّر عناوين URL، فالمنصات تولد بنى slug وتسلسلات فئات وترقيم صفحات مختلفة. خطط خريطة URL قبل الالتزام بمنصة.
• لا تنتقل التحويلات تلقائيًا. من الأخطاء الكلاسيكية فقد التحويلات القديمة في .htaccess عند تغيير المضيف. اجمع القواعد من CMS وCDN وإعداد الخادم وتقرير Page with redirect في GSC قبل بناء الطبقة الجديدة.
• أعد تنفيذ البيانات المنظمة، ولا تفترض انتقال schema، وتحقق منها بعد الإطلاق.
• اختبر عرض JavaScript عند الانتقال إلى واجهة headless/SPA؛ فالعرض يغير طريقة معالجة Googlebot للصفحات، وهو من أهم فحوصي بعد الترحيل.
• قِس سرعة الصفحة والجوال مرجعيًا. القوالب الجديدة غالبًا أثقل، وGoogle تفهرس نسخة الجوال، فتأكد من أنها ليست أبطأ أو معطلة.
• وحّد الشرطة المائلة الأخيرة، لأن المنصات تختلف فيها وعدم الاتساق ينشئ سلاسل خفية.
• أعد نشر وسوم التحليلات والتوثيق مثل GA4 وGSC ومدير الوسوم قبل الإطلاق.
• إعادة هيكلة كبيرة تغير العناوين والروابط والقوالب معًا تمنع Google من الاحتفاظ بفهمها القديم، فتوقع استقرارًا أطول من نقل مماثل.

النوع 4 — بنية URL / إعادة هيكلة الموقع

ما هو: تغيير مسارات URL على النطاق نفسه، مثل /category/post/ ← /post/. يبقى النطاق وقد يتغير المحتوى أو لا يتغير.

الخطر: متوسط. تبقى سلطة النطاق، لكن كل URL متغير يحتاج إلى تحويل وتحتاج شبكة الروابط الداخلية إلى تحديث.

المحاذير والخطوات الإلزامية:

• الروابط الداخلية هي ما ينساه الناس. كثيرًا ما تُحوّل العناوين وتنسى rel=canonical أو التنقل أو التذييل أو روابط النص. تصعّب هذه الإشارات القديمة اختيار Google للعناوين الجديدة حتى مع التحويلات.
• قد يتأخر توحيد canonical. إذا كانت للقديم روابط خلفية أكثر وظلت الروابط الداخلية تشير إليه، فقد تفضله Google بعد 301. تحديث الروابط مباشرة إلى الجديد حاسم.
• لا تستخدم Change of Address لإعادة الهيكلة داخل النطاق؛ أضف التحويلات وحدّث ملفات sitemap.
• حدّث مسارات التنقل والتنقل وsitemap إلى المسارات الجديدة، على أن تسرد sitemap العناوين الجديدة فقط.

النوع 5 — إعادة تصميم الموقع (العناوين نفسها)

ما هو: إعادة تصميم يبقى فيها النطاق والعناوين، لكن تتغير القوالب أو النصوص أو التنقل أو الصور أو عناصر SEO في الصفحة. وهو الأقل خطرًا، لا عديم الخطر.

الخطر: منخفض، لكن تغييرات الصفحة قد تحرك الترتيب.

المحاذير والخطوات الإلزامية:

• تتعطل عناصر الصفحة بصمت. كثيرًا ما تحذف إعادة التصميم أو تغيّر وسوم <title> والأوصاف وبنية العناوين والبيانات المنظمة. طابق كل عنصر بخط أساس الموقع القديم.
• راقب الروابط الداخلية. قد يزيل تصميم التنقل روابط داخلية عالية القيمة كانت تمرر السلطة إلى صفحات عميقة.
• قِس Core Web Vitals قبل وبعد. تغير CSS وJS والخطوط والصور سرعة الصفحة غالبًا.
• تعمد تغييرات المحتوى. كثيرًا ما تقلل إعادة تصميم «العنوان نفسه» المحتوى أو تدمجه، فلا تفترض أداء الصفحة الأخف بالمثل.
• مرجعك هنا إرشادات Google بشأن نقل الموقع بلا تغيير URL، التي تقلل الأثر عند تغيير البنية التحتية أو العرض مع ثبات العناوين.

النوع 6 — نطاق فرعي ↔ مجلد فرعي

ما هو: نقل المحتوى بين نطاق فرعي ومجلد فرعي، غالبًا blog.example.com ← example.com/blog/. يدمج التوحيد سلطة كانت موزعة بين مضيفين.

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

المحاذير والخطوات الإلزامية:

• الإصداران كيانان منفصلان لدى Google، بميزانية زحف وإشارات منفصلة جزئيًا. غالبًا يكون الدمج في مجلد إيجابيًا، لكنه يستغرق وقتًا ويتصرف كنقل حقيقي.
• لا تستخدم Change of Address لنقل نطاق فرعي إلى مجلد ضمن الجذر نفسه؛ فهذا من عائلة www/non-www التي تعالجها Google عبر canonical والتحويلات.
• ملكيات GSC: لديك غالبًا ملكيتان للنطاق الفرعي والجذر. بعد الدمج تتدفق البيانات إلى الجذر؛ راقب انخفاض تغطية الفرعي ونمو الجذر.
• حوّل كل URL في الفرعي إلى مكافئه في المجلد وحدّث الروابط الداخلية لتشير إليه مباشرة. تمرر 301 ملف الروابط الخلفية كله إلى النطاق الرئيسي، ويظل التواصل بشأن أهم الروابط مفيدًا.
• سوِّ التحليلات، فإذا كان للفرعي تتبع مستقل أو عبر النطاقات فأعد إعداد GA4 كي لا تفقد الاستمرارية.

النوع 7 — دمج النطاقات / المواقع

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

الخطر: مرتفع جدًا. ليس ترحيلًا قياسيًا؛ فلا نقل 1:1 للإشارة إليه، والكيان المدمج موقع جديد فعليًا في نظر Google بوجوه كثيرة. وكما صاغ Martin Splitt الأمر، فإن جمع موقعين أقرب إلى إنشاء موقع جديد من نسخة ممزوجة منهما.

المحاذير والخطوات الإلزامية:

• لا يمكنك استخدام Change of Address، لأنها تفترض نقلًا 1:1 من نطاق لآخر؛ أما الدمج فعمل لكل URL.
• توقع فقد بعض الزيارات. تحذر Google من أن نقل A وB وC جميعًا إلى موقع D قد يسبب ارتباكًا وخسارة؛ خطط لفترة استقرار ممتدة.
• أزل التكرار أولًا. إذا تداخلت المواقع موضوعيًا فسيخلق الدمج محتوى مكررًا؛ اختر صفحة canonical لكل موضوع قبل التحويل.
• حوّل كل URL إلى الصفحة الأكثر صلة، ولا تحول نطاقًا مستحوذًا عليه كله إلى الرئيسية، فهذا 404 ناعم لكل ما عدا الرئيسية. تنتقل قيمة الروابط أفضل عندما تذهب كل صفحة إلى مكافئها.
• احتفظ بملكية GSC لكل موقع مدمج وراقب تغطيتها المتناقصة مع نمو النطاق الأساسي.

اختر الدليل المتخصص

استخدم الدليل المطابق للقرار أو نمط الفشل الذي تحتاج إلى حله:

• SEO لترحيل الاستضافة — لتغييرات الخادم أو CDN أو DNS أو الاستضافة مع ثبات URL.
• SEO لترحيل CMS — لتغييرات المنصة وCMS، بما فيها مخاطر تكافؤ القالب والعرض والبيانات.
• ترحيل بنية URL — لتغييرات المسار أو التصنيف أو المجلد على النطاق نفسه.
• ترحيل SEO لتقسيم الموقع / اقتطاعه — لنقل قسم محدد من موقع إلى ملكية منفصلة.
• تكامل SEO بعد الاستحواذ — لتقرير كيفية دمج المواقع والعلامات والمحتوى المستحوذ عليها.
• فقد الزيارات بعد الترحيل — لتشخيص الظهور أو الزيارات التي لا تتعافى بعد الإطلاق.

موضع هذا الموضوع

يمس الترحيل موضوعات مجاورة كثيرة: عمليات إعادة التوجيه التي تحمله، واختيار canonical الذي يقرر أي URL تحتفظ به Google، وبروتوكول HTTPS، وhreflang للمواقع الدولية، وأداة Change of Address التي تشير إلى نقل نطاق. ولكل منها شرح مستقل، لكن عمود كل ترحيل واحد: اربط القديم بالجديد 1:1، وحوّل تحويلًا دائمًا، وأبق التحويلات، ثم راقب الإشارات الصحيحة.

ملخص الذكاء الاصطناعي

خلاصة مركزة من النسخة المتقدمة:

• ترحيل الموقع هو أي تغيير كبير في عناوينه أو نطاقه أو منصته أو بروتوكوله أو مضيفه يمكن أن يؤثر في الزحف والفهرسة والترتيب. الخطر = حجم التغيير × مقدار ما تغيره دفعة واحدة.
• الأنواع السبعة حسب الخطر: إعادة تصميم (العناوين نفسها، منخفض) ← HTTP إلى HTTPS (منخفض–متوسط) ← إعادة هيكلة URL (متوسط) ← نطاق فرعي إلى مجلد فرعي (متوسط–مرتفع) ← تغيير CMS (مرتفع) ← تغيير النطاق/العلامة (الأعلى) ← دمج النطاقات (مرتفع جدًا).
• العملية العامة ذات المراحل السبع: التخطيط والتصنيف ← قياس الموقع القديم والزحف إليه ← خريطة URL بنسبة 1:1 ← استراتيجية التحويل ← الاختبار وما قبل الإطلاق ← الإطلاق ← المراقبة بعده.
• 301/308 هما العمود الفقري. تنقلان الترتيب ولا تفقدان PageRank. وما عدا ذلك، مثل Change of Address وsitemap والروابط الداخلية وcanonical، إشارات مساندة.
• اربط القديم بالجديد 1:1. لا تحول عناوين كثيرة إلى الرئيسية، إذ تعامل كـ404 ناعم. تجنب السلاسل واجعلها دون نحو 3–5 قفزات. أبقِ التحويلات أطول بكثير من «12 شهرًا»، وعمليًا إلى الأبد للمستخدمين.
• توقع تذبذبًا مؤقتًا ثم تعافيًا. والانخفاض العالق يعني غالبًا عطلًا: حظر اختبار بقي مباشرًا، أو hreflang/canonical محذوف، أو noindex شارد، أو وجهات خاطئة، لا النقل نفسه.
• Change of Address: للنطاق الكامل فقط، وبنسبة 1:1 صارمة، واختيارية. ليست لـHTTP إلى HTTPS ولا لإعادة الهيكلة داخل النطاق ولا للدمج.
• Bing: أداة Site Move القديمة مهملة منذ نحو 2021؛ استخدم IndexNow لإرسال العناوين المنقولة. ويميل Bing إلى إبقاء التحويلات 1–2 سنة.

الوثائق الرسمية

وثائق مصادر أولية من محركات البحث.

Google

• نقل الموقع مع تغيير عناوين URL — دليل الترحيل الأساسي: التحويلات والتوقيت والتوقعات وإبقاؤها قرابة عام.
• نقل الموقع بلا تغيير عناوين URL — نقل الاستضافة/البنية وإعادة التصميم؛ أسماء المضيف المؤقتة وتحذيرات DNS وجدار الحماية وDoS.
• عمليات إعادة التوجيه وبحث Google — التحويلات الدائمة والمؤقتة وخطر تحويل JavaScript.
• أداة Change of Address (مساعدة Search Console) — نطاق النقل المدعوم ومتطلبات الملكية والاستثناءات وإرشادات التحويل.
• توحيد عناوين URL المكررة — تفضيل HTTPS بوصفه canonical، ولماذا تمثل 301 إشارة canonical أقوى من التحويل المؤقت.
• اختيار canonical — كيف تختار Google عنوان canonical؛ فهو تلميح لا توجيه ملزم.
• تفعيل HTTPS على خوادمك (web.dev) — شهادات TLS والمحتوى المختلط وإرشادات HSTS، وقد أصبحت وثائق Google القديمة لـHTTPS تحيل إليه.

Bing / Microsoft

• ترحيل الموقع مع Bing — إطار ترحيل Bing ومدة التحويل ومراقبة السجلات بعد الترحيل.
• IndexNow — الآلية الحالية لإرسال العناوين المنقولة إلى Bing، بعد إهمال Site Move القديمة.

اقتباسات من المصدر

تصريحات مسجلة رسميًا من Google. كل رابط عميق ينتقل إلى المقطع المقتبس في صفحة المصدر.

Google — عمليات إعادة التوجيه وPageRank

• “301 and other permanent redirects don’t cause a loss in PageRank.” (ترجمة) «لا تسبب 301 وغيرها من عمليات إعادة التوجيه الدائمة خسارة في PageRank». — Search Central، نقل الموقع مع تغيير URL. انتقل إلى الاقتباس
• “keep the number of redirects in the chain low, ideally no more than 3 and fewer than 5” (ترجمة) «أبقِ عدد عمليات إعادة التوجيه في السلسلة منخفضًا، ويفضل ألا يزيد على 3 وأن يقل عن 5». — Search Central، نقل الموقع مع تغيير URL. انتقل إلى الاقتباس
• “Keep the redirects for as long as possible, generally at least 1 year.” (ترجمة) «أبقِ عمليات إعادة التوجيه لأطول مدة ممكنة، وعمومًا سنة واحدة على الأقل». — Search Central، نقل الموقع مع تغيير URL. انتقل إلى الاقتباس
• “Don’t redirect many old URLs to one irrelevant single URL destination, such as the home page” (ترجمة) «لا تعِد توجيه عناوين URL قديمة كثيرة إلى وجهة URL واحدة غير ذات صلة، مثل الصفحة الرئيسية». — Search Central، نقل الموقع مع تغيير URL. انتقل إلى الاقتباس

Google — التوقعات والتوقيت

• “Expect temporary fluctuation in site ranking during the move.” (ترجمة) «توقع تذبذبًا مؤقتًا في ترتيب الموقع أثناء النقل». — Search Central، نقل الموقع مع تغيير URL. انتقل إلى الاقتباس
• “a medium-sized website can take a few weeks for most pages to move in our index” (ترجمة) «قد يستغرق انتقال معظم صفحات موقع متوسط الحجم في فهرسنا بضعة أسابيع». — Search Central، نقل الموقع مع تغيير URL. انتقل إلى الاقتباس
• “Check your redirects from the old site to the new one. We frequently see people redirecting to the wrong (non-existent) URLs.” (ترجمة) «تحقق من عمليات إعادة التوجيه من الموقع القديم إلى الجديد. نرى كثيرًا أشخاصًا يعيدون التوجيه إلى عناوين URL خاطئة (غير موجودة)». — Search Central، نقل الموقع مع تغيير URL. انتقل إلى الاقتباس

Google — أداة Change of Address (نافذة 180 يومًا)

• “Maintain the redirects for at least 180 days—longer if you still see any traffic to them from Google Search.” (ترجمة) «حافظ على عمليات إعادة التوجيه 180 يومًا على الأقل، ولمدة أطول إذا استمرت الزيارات إليها من بحث Google». — مساعدة Search Console، Change of Address. اقرأ المصدر
• “After the 180 day period, Google does not recognize any relationship between the old and new sites, and treats the old site as an unrelated site.” (ترجمة) «بعد مدة 180 يومًا لا تعترف Google بأي علاقة بين الموقعين القديم والجديد، وتعامل الموقع القديم كموقع غير ذي صلة». — مساعدة Search Console، Change of Address. اقرأ المصدر

Google — إشارات HTTPS وcanonical وإعادة التوجيه

• “Google prefers HTTPS pages over equivalent HTTP pages as canonical, except when there are issues or conflicting signals.” (ترجمة) «تفضل Google صفحات HTTPS على صفحات HTTP المكافئة بوصفها canonical، إلا عند وجود مشكلات أو إشارات متعارضة». — Search Central، توحيد عناوين URL المكررة. انتقل إلى الاقتباس
• “Googlebot follows the redirect, but the indexing pipeline doesn’t use the redirect as a signal that the redirect target should be canonical.” (ترجمة) «يتبع Googlebot إعادة التوجيه، لكن مسار الفهرسة لا يستخدمها إشارةً إلى أن وجهتها ينبغي أن تكون canonical». (عن التحويلات المؤقتة) — Search Central، عمليات إعادة التوجيه وبحث Google. انتقل إلى الاقتباس

Google — تحذيرات الإطلاق والبنية التحتية

• “Make sure it does not block Googlebot’s ability to reach the DNS or the hosting provider’s servers.” (ترجمة) «تأكد من أنه لا يحجب قدرة Googlebot على الوصول إلى DNS أو خوادم موفر الاستضافة». (جدار الحماية / حماية DoS) — Search Central، نقل الموقع بلا تغيير URL. انتقل إلى الاقتباس
• “it’s normal to see a temporary drop in Googlebot’s crawl rate immediately after the launch, followed by a steady increase over the next few days.” (ترجمة) «من الطبيعي رؤية انخفاض مؤقت في معدل زحف Googlebot بعد الإطلاق مباشرة، يعقبه ارتفاع ثابت خلال الأيام القليلة التالية». (نقل الخادم/الاستضافة) — Search Central، نقل الموقع بلا تغيير URL. انتقل إلى الاقتباس

قائمة فحص الترحيل الرئيسية

نفّذها في كل ترحيل أيًا كان نوعه، ثم أضف القائمة الخاصة بالنوع تحتها.

قبل الإطلاق

• صُنّفت كل أنواع الترحيل الموجودة وتُجنب تكديس الأنواع عالية الخطر.
• أُبلغ أصحاب المصلحة بأن الانخفاض المؤقت طبيعي، وحُدد الإطلاق وقت انخفاض الزيارات.
• وُثقت خطة التراجع واختُبرت.
• حُفظ زحف كامل للموقع القديم كخط أساس لضمان الجودة.
• صُدّرت الترتيبات وأداء GSC لـ3/6/12 شهرًا وGA4 وأهم الصفحات حسب الروابط الخلفية.
• جُمعت كل التحويلات من CMS وCDN وإعداد الخادم وتقرير Page with redirect في GSC.
• بُنيت خريطة القديم←الجديد 1:1 لكل عنوان؛ المحذوف ← 410/404 لا الرئيسية.
• تستخدم الخطة 301/308 بقفزة واحدة بلا سلاسل وتشمل الصور وPDF.
• مُنعت فهرسة الاختبار بـnoindex و/أو robots.txt، وسُجل الحظر لإزالته عند الإطلاق.
• قورن زحف الاختبار بالأساس للعناوين والأوصاف وcanonical وhreflang والبيانات المنظمة وmeta robots والروابط والسرعة.
• تشير canonical في الاختبار إلى العناوين المباشرة لا عناوين الاختبار.
• اختُبر كل تحويل من القديم إلى الجديد وتأكد الوصول للصفحة المقصودة بقفزة واحدة.
• حضرت وسوم التحليلات/التوثيق واختُبرت النماذج ومسارات التحويل.
• تأكد أن جدار الحماية/DoS لا يحجب Googlebot.

يوم الإطلاق

• أُزيل كل حظر زحف للاختبار (noindex وrobots.txt) وتحقق منه مباشرة.
• فُعلت جميع عمليات 301.
• حُدثت ملفات sitemap XML للإنتاج بالعناوين الجديدة فقط وأُعيد إرسالها في GSC.
• عند الحاجة أُرسل ملف منفصل مؤقت للعناوين القديمة لاكتشاف التحويلات أو مراقبتها، مع مالك وشرط إزالة.
• فُحصت عينات التحويل عبر URL Inspection في GSC.
• أُرسلت Change of Address لنقل النطاق الكامل فقط.
• أُرسلت العناوين المنقولة إلى Bing عبر IndexNow.
• تأكدت سعة الخادم للزحف الأثقل بعد الإطلاق.

بعد الإطلاق

• أُعيد الزحف الجماعي إلى قائمة العناوين القديمة، وكل عنوان يعطي 301 إلى الصفحة الصحيحة.
• حُدثت الروابط الداخلية لتشير إلى الجديد مباشرة بلا روابط قديمة.
• رُوقبت فهرسة الصفحات والأداء حسب الصفحة وإحصاءات الزحف والإجراءات اليدوية في GSC.
• التُقطت الترتيبات أسبوعيًا في الشهر الأول.
• طُلب من أهم أصحاب الروابط الخارجية تحديث روابطهم.
• جُدولت التحويلات للبقاء سنوات، لا 180 يومًا فقط.
• إذا انخفضت الزيارات وبقيت، فُحصت أولًا hreflang المحذوفة وnoindex الشاردة وcanonical المعطلة والتحويلات السيئة.

قوائم الفحص الخاصة بكل نوع

النوع 1 — تغيير النطاق / العلامة

• فُحص تاريخ الاستخدام السابق للنطاق الجديد في archive.org وأُمّنت تجديدات القديم.
• تأكدت ملكية خصائص GSC القديمة والجديدة المؤهلة غير المقيدة بمسار: Domain أو URL-prefix جذرية، لا URL-prefix لمسار.
• وُضعت 301 من الرئيسية القديمة إلى الجديدة، وهو شرط للأداة.
• حُدثت canonical والروابط الداخلية وsitemap للنطاق الجديد في الموقع كله.
• أُرسلت Change of Address لكل نطاق فرعي ولكل صيغة www/non-www.
• نُقل ملف التنصل إلى الملكية الجديدة، ولم يُجمع النقل مع إعادة تصميم/هيكلة.

النوع 2 — HTTP ← HTTPS

• شهادة صالحة (RSA‏ 2048 بت/EC) وتقييم Qualys‏ A/A+، و301 لكل URL من HTTP إلى HTTPS، لا تحويل عام للرئيسية.
• فُحص المحتوى المختلط وأُصلح بعناوين نسبية/نسبية للبروتوكول وسياسة CSP‏ upgrade-insecure-requests.
• حُدثت canonical وsitemap وrobots.txt وhreflang إلى HTTPS، وأضيفت Secure للكوكيز.
• أضيف HSTS فقط بعد ثبات TLS، بدءًا من max-age منخفض.
• لم تُستخدم Change of Address، بل إرشادات نقل الموقع.

النوع 3 — تغيير المنصة / CMS

• بُنيت خريطة القديم←الجديد قبل تثبيت اختيار المنصة.
• جُمعت قواعد التحويل من CMS وCDN والخادم وGSC، بما فيها قواعد .htaccess.
• وُحدت الشرطة المائلة الأخيرة، وأُعيد بناء البيانات المنظمة والتحقق منها.
• اختُبر عرض JavaScript عند استخدام headless/SPA وقيس عرض الجوال والسرعة.
• أُعيد نشر GA4 وGSC ومدير الوسوم على المنصة الجديدة.

النوع 4 — بنية URL / إعادة الهيكلة

• بُنيت خريطة القديم←الجديد كاملة ونُفذت 301 لكل عنوان.
• حُدثت كل الروابط الداخلية: التنقل ومسارات التنقل والتذييل والنص وأدوات المنشورات ذات الصلة.
• حُدث rel=canonical إلى الجديد، وصارت sitemap تسرد الجديد فقط.
• لم تُستخدم Change of Address لإعادة الهيكلة داخل النطاق؛ استُخدمت التحويلات وتحديث sitemap.
• زُحف إلى الموقع الجديد للتأكد من عدم بقاء روابط داخلية نحو عناوين قديمة محولة.

النوع 5 — إعادة تصميم الموقع (العناوين نفسها)

• حُفظت عناصر الصفحة من الموقع القديم، مثل العناوين والأوصاف وH1 وcanonical والبيانات المنظمة، وقورنت بعد الإطلاق.
• حُفظت الروابط الداخلية عالية القيمة أثناء إعادة تصميم التنقل.
• قيس Core Web Vitals قبل وبعد.
• كانت تغييرات المحتوى مقصودة بلا تقليل عارض، واستمرت التحليلات.

النوع 6 — نطاق فرعي ↔ مجلد فرعي

• زُحف إلى النطاق الفرعي وبُنيت خريطة blog.example.com/post/ ← example.com/blog/post/ كاملة.
• وُضعت 301 من كل URL فرعي إلى مكافئ المجلد، وحُدثت الروابط الداخلية لتشير إليه مباشرة.
• لم تُستخدم Change of Address للنقل داخل الجذر نفسه.
• رُوقبت ملكيتا GSC، مع انخفاض تغطية الفرعي ونمو الجذر، وأُعيد إعداد التحليلات.

النوع 7 — دمج النطاقات / المواقع

• رُوجع كل موقع مدمج عبر الزحف والترتيب والروابط الخلفية وGSC.
• أزيل تداخل المحتوى واختيرت صفحة canonical لكل موضوع قبل التحويل.
• وُضعت 301 لكل URL إلى الصفحة الأكثر صلة، لا تحويل عام للرئيسية.
• لم تُستخدم Change of Address لغياب نقل 1:1، وخُطط لاستقرار ممتد.
• احتُفظ بملكية GSC لكل موقع مدمج ورُوقبت تغطيته مع النطاق الأساسي.

النماذج الذهنية

1. الخطر = حجم التغيير × مقدار ما تغيره دفعة واحدة. صنّف الأنواع قبل كل شيء. إعادة تصميم بالعناوين نفسها تغيير واحد منخفض الخطر، بينما يجمع نقل النطاق وإعادة هيكلة URL وتغيير المنصة ثلاثة أنواع عالية الخطر. إن استطعت تنفيذ التغيير مرحليًا، فغيّر شيئًا واحدًا في كل مرة.

2. التحويلات تؤدي العمل؛ وكل شيء آخر يعطي إشارات. عمليات إعادة التوجيه الدائمة هي الآلية التي تنقل الترتيب. أما Change of Address وإرسال sitemap وتحديث الروابط الداخلية وcanonical فكلها إشارات مساندة تساعد محركات البحث على معالجة النقل أسرع وأنظف. ابن التحويلات أولًا، وتعامل مع البقية كعوامل مسرّعة لا بدائل.

3. التعيين 1:1 أفضل من تحويل الجميع إلى الرئيسية. يرتبط كل URL قديم بأكثر URL جديد صلة به. وتعامل مجموعة التحويلات إلى الرئيسية كخطأ ناعم لصفحة غير موجودة، فلا فائدة وتضيع قيمة الرابط الخاصة بالصفحة. لا بديل؟ أعد استجابة 410 أو 404 صحيحة بدل الرئيسية.

4. نافذة الأداة ليست عمر التحويل. تنقل Change of Address الإشارات 180 يومًا. وينبغي أن تستمر التحويلات بعدها سنوات، ما دامت العناوين القديمة تجلب زيارات أو روابط. إنهما جدولان، والأطول، أي التحويلات، هو ما يثبت النقل.

5. الانخفاض طبيعي؛ وبقاؤه عطل. توقع تذبذبًا مؤقتًا وتعافيًا خلال أسابيع إلى شهرين. إن لم تعد الزيارات فلا تلق اللوم على «النقل»، بل ابحث عن المعتاد: حظر اختبار بقي مباشرًا، أو hreflang محذوف، أو noindex شارد، أو canonical معطلة، أو تحويلات إلى صفحات خاطئة.

6. الروابط الداخلية تهم بقدر التحويلات في اختيار canonical. قد تحول كل شيء بدقة وتظل Google تفهرس القديم إذا أشارت إليه روابط التنقل والتذييل والنص والروابط الخارجية. حدّث الداخلية مباشرة إلى الجديد، وتواصل بشأن أهم الروابط الخارجية.

ورقة ترحيل مرجعية

متى تستخدم كل نوع تحويل؟

الأداة أو الإشارة المناسبة لكل ترحيل

مكافئات Bing

حقائق سريعة

• لا تفقد 301 قيمة PageRank، وقد ماتت الخرافة منذ نحو 2016.
• سلاسل التحويل: أبقها دون نحو 3–5 قفزات، ويتبع Googlebot نحو 10.
• 180 يومًا هي نافذة Change of Address، لا موعد إزالة التحويل؛ أبقها عمليًا إلى الأبد.
• زمن إعادة الفهرسة: «بضعة أسابيع» لموقع متوسط وأطول للكبير.
• أهم سبب لانخفاض عالق: وسوم مفقودة/شاردة في الجديد، مثل hreflang وnoindex وcanonical، لا النقل.

ما نوع هذا الترحيل، وهل تنطبق Change of Address؟

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

خطة عمل: انخفضت الزيارات بعد الإطلاق ولا تتعافى

استخدم هذه الخطة عندما لا يستقر التذبذب المتوقع بعد الإطلاق. ابدأ من إخفاقات الوصول على مستوى الموقع وانتقل إلى تعارض إشارات كل URL؛ ولا تلم «النقل» قبل تبرئة التنفيذ.

الخطوة 1 — تأكد أن الانخفاض حقيقي ومحدد النطاق. قارن الصفحات والاستعلامات والأسواق وتعريفات التحليلات نفسها التي قستها قبل الإطلاق. إن اختفت التقارير فقط فأصلح القياس أولًا. إن فقدت العناوين القديمة ظهورها بينما كسبته الجديدة المكافئة، فاستمر في مراقبة الانتقال الطبيعي. وإن خسرت المجموعتان، فانتقل إلى الخطوة 2.

الخطوة 2 — افحص حظر الزحف أو الفهرسة على مستوى الإطلاق. اجلب الإنتاج كزاحف وافحص robots.txt وmeta robots وX-Robots-Tag والمصادقة واستجابات جدار الحماية وDNS ورموز الحالة. إذا نُشر noindex أو Disallow: / أو جدار مصادقة أو حظر روبوتات من الاختبار، فأزله وأعد الزحف فورًا. وإن كان الإنتاج متاحًا وقابلًا للفهرسة، فتابع.

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

الخطوة 4 — قارن الصفحات الجديدة بخط الأساس. قارن canonical وhreflang وعناوين الصفحات وعناوين الأقسام ونص الصفحة والبيانات المنظمة والروابط الداخلية وHTML المرئي بعد العرض. إذا اختفى وسم في القالب كله أو أشار إلى الاختبار أو القديم، فأصلح القالب قبل الصفحات الفردية. وإن بقي التكافؤ، فتابع.

الخطوة 5 — افحص إشارات التوحيد. تأكد أن العناوين الجديدة ذاتية canonical، وأن الروابط الداخلية والتنقل تشير إليها مباشرة، وأن ملفات sitemap الحالية تسرد العناوين الجديدة فقط. إذا أُرسل ملف منفصل للقديم للمراقبة فتأكد من استمرار فائدته واحذفه عند انتهائها. افحص عينة من canonical التي اختارتها Google عبر URL Inspection. وإذا ظلت تختار القديم أو عناوين غير ذات صلة، فأزل الروابط وcanonical ومدخلات sitemap المتعارضة ثم انتظر إعادة الزحف.

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

الخطوة 7 — استخدم التراجع فقط عند ثبوت انحدار منشور. تراجع عندما يتحقق المحفز المتفق عليه وتربط مقارنة الزحف الانخفاض بعيب قابل للعكس في القالب أو المنصة أو الإعداد. لا تتراجع لمجرد تقلب اليوم الأول؛ فالنقل الثاني غير المخطط يضيف ترحيلًا آخر تعالجه المحركات.

خرافات الترحيل التي تصنع إخفاقات حقيقية

«عمليات إعادة التوجيه الدائمة تفقد قيمة الروابط». لماذا هذا خطأ: تقول Google إنها لا تفقد PageRank. الخطر العملي هو وجهة خاطئة أو سلسلة أو حلقة أو طريق مسدود، لا 301 نفسها. افعل بدلًا من ذلك: اربط كل URL قديم بأقرب مكافئ مباشرة واختبر الاستجابة النهائية.

«Change of Address تنقل الموقع عني». لماذا هذا خطأ: الأداة إشارة مساندة اختيارية لنقل صارم للنطاق كله. لا تنشئ التحويلات ولا تدعم HTTPS أو تغييرات المسار أو النقل الجزئي أو الدمج. افعل بدلًا من ذلك: ابن خريطة التحويل أولًا، ثم استخدم الأداة فقط إذا طابق نطاقها.

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

«يمكن إزالة التحويلات بعد بضعة أشهر». لماذا هذا خطأ: إرشاد Google لعام واحد حد أدنى لمعالجتها، لا تاريخ انتهاء للإشارات المرجعية والروابط الخلفية والمستخدمين. افعل بدلًا من ذلك: أبق التحويلات ما دامت العناوين القديمة تتلقى زيارات أو روابط، أي غالبًا بلا أجل، واحتفظ بالسيطرة على النطاق القديم.

أدوات تعيين الترحيل والتحقق منه

• منشئ خريطة إعادة التوجيه — ألصق مجموعتي URL القديمة والجديدة لإنشاء خريطة 301 مقترحة بدرجات ثقة وصفوف بلا مطابقة وقائمة 410 وتسطيح للسلاسل وتجاوزات يدوية وصادرات للمنصات. كل اقتراح يحتاج مراجعة تحريرية للتكافؤ قبل الإطلاق.
• مخطط سلسلة إعادة التوجيه — تتبع كل قفزة وشاهد الحالة وتغير المضيف/المسار وmeta refresh وقواعد التنظيف. استخدمه على عينات الاختبار وإخفاقات ما بعد الإطلاق حيث قد تتراكم قواعد الشرطة أو البروتوكول أو النطاق.
• فاحص إعادة التوجيه — تحقق سريعًا من الحالة والقفزات والوجهة لعنوان واحد أو دفعة صغيرة. استخدم زاحفًا كاملًا لمخزون القديم؛ فلا تثبت العينات الخريطة كلها.
• زاحف موقع كامل — يحفظ خط الأساس قبل الترحيل، ويختبر قائمة التحويلات كاملة، ويقارن العناوين وcanonical وhreflang والتوجيهات والروابط وschema والعرض.
• Google Search Console — استخدم Page Indexing وPerformance وSitemaps وCrawl Stats وURL Inspection، وChange of Address فقط عند نقل نطاق كامل مؤهل.
• سجلات وصول الخادم — تثبت وصول روبوتات البحث إلى المضيف الجديد والاستجابات التي تتلقاها واستمرار طلب القديم قبل إيقاف البنية التحتية.

أثبت أن الترحيل نُشر كما خُطط

اختبار تحويل قائمة URL القديمة كاملة

• الاختبار: ازحف إلى مخزون URL القديم الكامل من المرحلة 2 على الإنتاج، وافحص الإخفاقات عبر مخطط سلسلة إعادة التوجيه أو فاحص إعادة التوجيه.
• النتيجة المتوقعة: يعطي كل URL منقول قفزة خادم واحدة 301 أو 308 إلى مكافئه المقصود، ويعطي المحذوف عمدًا 404 أو 410 المخطط.
• تفسير الفشل: استجابة 200 على القديم أو سلسلة أو حلقة أو وجهة غير ذات صلة أو 404 غير مخطط تعني أن الخريطة أو ترتيب القواعد لم يُنشر كما أُقر.
• نافذة المراقبة: بعد الإطلاق مباشرة، ثم مع نشر الإصلاحات وفي النافذة المبكرة حيث يظل زحف القديم كثيفًا.
• محفز التراجع: ترسل قاعدة تعيين منهجية قسمًا محميًا مهمًا إلى وجهات خاطئة أو تجعله غير متاح ولا يمكن إصلاحها بأمان في موضعها.

اختبار قابلية فهرسة الصفحة الجديدة وcanonical

• الاختبار: ازحف إلى المجموعة الجديدة وافحص الحالة وتوجيهات robots وcanonical، ثم استخدم URL Inspection لصفحات عالية القيمة ممثلة.
• النتيجة المتوقعة: تعطي الصفحات 200، ولا تكون محجوبة أو noindex، وتعلن canonical الجديد المقصود؛ وبعد إعادة الزحف تبلغ Google عن canonical المقصود في العينات.
• تفسير الفشل: توجيه اختبار شامل أو canonical قديم/اختباري أو تحدي مصادقة أو اختيار Google لعنوان مختلف يعني تعارض إعداد الإطلاق.
• نافذة المراقبة: الإشارات التقنية فورية، أما canonical الذي تختاره Google وحركة الفهرس فتحتاجان إعادة الزحف وقد تستغرقان أسابيع لموقع متوسط وأطول على نطاق واسع.
• محفز التراجع: حظر زحف/فهرسة على الإنتاج كله أو عيب canonical في القالب يؤثر في المجموعة المحمية ولا يمكن إزالته سريعًا دون رد الإصدار.

اختبار وجهات الروابط وsitemap

• الاختبار: ازحف إلى الروابط الداخلية وحلل ملفات sitemap المرسلة، وقارن كل وجهة بمجموعة URL الجديدة المعتمدة بوصفها canonical.
• النتيجة المتوقعة: تشير الروابط والتنقل مباشرة إلى الجديد، وتسرد sitemap للإنتاج العناوين الجديدة الناجحة فقط. وأي ملف للقديم منفصل ومؤقت ومرتبط بشرط إزالة.
• تفسير الفشل: الروابط القديمة أو مزج القديم والجديد في sitemap أو إبقاء ملف القديم بعد انتهاء دليله المفيد قد يبطئ الانتقال أو يحجبه.
• نافذة المراقبة: فورية في الموقع المعروض وملفات sitemap؛ وتأكد من معالجة الملف المرسل أثناء مراقبة ما بعد الإطلاق.
• محفز التراجع: انحدار على مستوى قالب في التنقل أو مولد sitemap يعيد الزاحف إلى عناوين قديمة أو اختبارية أو غير canonical ولا يمكن إصلاحه سريعًا بأمان.

مصادر تستحق وقتك

كتاباتي ذات الصلة

• نجاح ترحيل الموقع يحتاج إلى أكثر من قائمة فحص — دليلي الكامل، مع الأخطاء الشائعة وقائمة مراقبة ما بعد الإطلاق.
• عمليات إعادة التوجيه لـSEO: دليل مبتدئ — أنواع التحويل والسلاسل ومدة إبقائها.
• هل يصح إزالة 301 بعد عام؟ اختبرنا ذلك — تجربة مباشرة وراء توصية الإبقاء الطويل.
• اختيار canonical: دليل مبتدئ — كيف تختار Google canonical حين تتنافس العناوين القديمة والجديدة بعد النقل.
• دليل المبتدئ إلى Technical SEO — موضع الترحيلات في الصورة الأكبر.

رسمية

• نقل الموقع مع تغيير URL — دليل Google الأساسي للترحيل.
• أداة Change of Address — نطاق النقل المدعوم ومتطلبات الملكية وإرشادات التحويل من Google.
• ترحيل الموقع مع Bing — إطار Bing وإرشادات مدة التحويل.

من الآخرين

• r/TechSEO — حيث تُشخص حالات الترحيل الطرفية وانخفاضات ما بعد الإطلاق.
• Mueller من Google عن مفاتيح نجاح ترحيل الموقع — إرشاداته بشأن تعيين URL والروابط الداخلية ولماذا لا تكفي التحويلات وحدها.
• Google: الترحيل النظيف يستغرق وقتًا، والمرقع أطول كثيرًا — نصيحة Mueller عن دمج المواقع وتكلفة اختصار الطريق.
• عند النقل من HTTP إلى HTTPS توصي Google بـ301 — توصية Mueller بعمليات 301 لكل URL بدل التحويل العام.
• ترحيل الموقع مع Bing — إطار Bing ذي الخطوات الثماني، وإرشاد 1–2 سنة للتحويل، ومراقبة السجلات.
• نقل النطاقات: تجنب المزالق — إرشاد Bing بشأن تاريخ النطاق الجديد وعدم استخدام canonical بدل التحويل.
• فعّل HTTPS على خوادمك — المرجع المعتمد لشهادات TLS والمحتوى المختلط وHSTS أثناء النقل.

توصي Google بإبقاء عمليات تحويل نقل الموقع لأطول مدة ممكنة، وعمومًا سنة على الأقل. Evidence for this claim Google recommends keeping site-move redirects as long as possible, generally for at least one year. Scope: Google Search's minimum site-move guidance; continuing user traffic or links can justify retaining redirects longer. Confidence: high · Verified: 2026-07-14 Google Search Central: Site move with URL changes وتقول إن تذبذب الترتيب مؤقت متوقع، وإن انتقال معظم صفحات موقع متوسط في فهرسها قد يستغرق بضعة أسابيع. Evidence for this claim Google says to expect temporary ranking fluctuations during a site move; most pages on a medium-sized site can take a few weeks to move in Google's index, and larger sites take longer. Scope: Google Search's general expectations for moves with URL changes; actual timing varies by site and does not promise recovery by a fixed date. Confidence: high · Verified: 2026-07-14 Google Search Central: Site move with URL changes وعندما يكون ذلك ممكنًا توصي بتغيير شيء رئيسي واحد كل مرة.

اختبر نفسك: ترحيل المواقع

خمسة أسئلة عن أنواع الترحيل والتحويلات وتشخيص ما بعد الإطلاق. اختر إجابة لكل سؤال ثم تحقق منها.

سجل التغييرات