نقل الموقع وتغيير الروابط: دليل التخطيط والتنفيذ والمتابعة

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

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

تاريخ النشر: 3 أكتوبر 2026.

انتقل مباشرة إلى تحديد نوع النقل، أو إعداد خريطة الروابط، أو خطوات ووردبريس، أو اختبارات الإطلاق، أو تشخيص المشكلات بعد النقل.

حدّد نوع النقل قبل تغيير أي إعداد

الدومين هو اسم النطاق، والاستضافة هي البنية التي تشغّل الموقع، بينما عنوان URL يحدد موضع صفحة أو ملف. ففي العنوان https://example.com/services/ يمثل example.com اسم النطاق، ويمثل /services/ المسار. تغيير أحد هذه الأجزاء لا يعني بالضرورة تغيير بقية الأجزاء.

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

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

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

إذا كنت تنقل الاستضافة فقط

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

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

جهّز سجلًا للموقع وخطة استعادة قبل التنفيذ

احصر العناوين التي يجب ألا تضيع

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

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

احتفظ ببيانات مرجعية قبل النقل: النقرات، ومرات الظهور، والصفحات والاستعلامات المهمة، مع الفترة والمرشحات المستخدمة. يتيح تقرير الأداء في Search Console تحليل البيانات حسب الصفحة وطلب البحث والجهاز والبلد؛ وهذا أدق من الاحتفاظ بصورة للزيارات الإجمالية فقط.

أنشئ نسخة احتياطية قابلة للاستعادة

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

اختبر الاستعادة في بيئة منفصلة قبل الاعتماد على النسخة. واحفظ النسخ في مكان محمي لا يمكن تنزيله عبر رابط عام؛ ملف قاعدة البيانات ليس مادة يجوز تركها داخل مجلد مكشوف للزوار.

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

احمِ بيئة الاختبار وحدد مسؤولية الإطلاق

استخدم وصولًا مقيدًا للنسخة التجريبية عندما تحتوي بيانات خاصة. لا تعتمد على robots.txt لحماية المعلومات؛ تشرح وثائق Google أنه يتحكم في وصول الزواحف، وليس وسيلة حماية للمحتوى.

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

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

أنشئ خريطة تربط كل رابط قديم بمصيره

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

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

المسار القديم	الوجهة أو القرار	النتيجة المطلوبة
/services/	/services/ على الدومين الجديد	تحويل دائم إلى صفحة الخدمات المقابلة.
/post?id=8	/guides/start/	تحويل إلى المحتوى نفسه بعنوانه الجديد.
/guide-a/ و/guide-b/	/complete-guide/	تحويل بعد دمج محتوى الصفحتين فعليًا.
/expired-offer/	إزالة دون بديل مناسب	استجابة 404 أو 410، لا تحويل غير مرتبط.
/files/catalog.pdf	/downloads/catalog.pdf	تحويل إلى الملف الصحيح مع إمكانية تنزيله.

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

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

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

اختبر الاستثناءات قبل تعميم القواعد

قد يناسب تغيير الدومين وحده نمط تحويل يحتفظ بالمسار، لكن هذا لا يكفي عندما تتغير المسارات أيضًا. مثلًا، نقل /post?id=8 إلى دومين جديد بالمسار نفسه لن يوصله إلى /guides/start/ ما لم تُحدد هذه العلاقة.

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

نفّذ التحويلات وحدّث الروابط والإشارات معًا

متى تستخدم 301 أو 308؟

للنقل الدائم، استخدم تحويلًا دائمًا من الخادم عندما يكون ذلك ممكنًا. تذكر وثائق Google لإعادة التوجيه أن 301 و308 يشيران إلى انتقال دائم. أما 302 و307 فيناسبان التحويل المؤقت؛ وجودهما ليس عقوبة، لكن يجب أن يطابق الاختيار طبيعة التغيير.

مكان التنفيذ يعتمد على بيئتك: إعدادات الخادم، أو المنصة، أو خدمة وسيطة تستقبل الطلبات. ملف .htaccess ليس وصفة لجميع الخوادم، وقواعد Apache لا تُنسخ كما هي إلى Nginx. اجعل ملف خريطة الروابط هو المرجع الذي يحوّله المسؤول التقني إلى الإعداد المناسب.

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

تغيير DNS ليس تحويلًا للروابط. توجيه الدومين إلى خادم آخر يحدد أين يُرسل الطلب، أما نقل الزائر من عنوان إلى آخر فيحتاج استجابة إعادة توجيه مناسبة. افحص النتيجة الفعلية بدل الاعتماد على اسم الخيار داخل لوحة الاستضافة.

لا تترك الموقع الجديد يشير إلى القديم

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

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

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

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

نقل موقع ووردبريس وتغيير الروابط الدائمة

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

عنوان ووردبريس ليس دائمًا عنوان الواجهة

في الإعدادات ← عام، يشير «عنوان ووردبريس» إلى موضع ملفات النظام، بينما يشير «عنوان الموقع» إلى العنوان الذي يستخدمه الزائر للوصول إلى الواجهة. قد يتطابقان، وقد يختلفان في إعدادات معينة، كما يوضح دليل الإعدادات العامة. لا تعدّل القيم على موقع قائم قبل تجهيز الوجهة وخطة الوصول إلى الإدارة بعد التغيير.

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

عاين البحث والاستبدال قبل حفظ التغييرات

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

wp search-replace 'https://example.com' 'https://example.org' --skip-columns=guid --dry-run

وفق مرجع WP-CLI، يعرض --dry-run تقرير المعاينة دون الكتابة في قاعدة البيانات، وتتعامل الأداة مع بيانات PHP المتسلسلة. راجع الجداول وعدد المواضع قبل اعتماد عملية فعلية؛ المثال يفحص النص المحدد، ولا يغطي تلقائيًا جميع صيغ HTTP وwww أو كل جداول الإضافات.

يستبعد المثال عمود guid لأن دليل WordPress يحذر من تغيير هذه المعرّفات أثناء النقل. لا تستبدل كل ظهور للدومين القديم لمجرد وجوده في قاعدة البيانات؛ افهم وظيفة الحقل أولًا. ولا تعمم المثال على شبكة Multisite أو تضف خيارات تشمل كل الجداول دون تحديد نطاق العمل.

تغيير الروابط الدائمة يحتاج اختبار العناوين القديمة

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

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

اختبر مسار الزائر قبل اعتماد الإطلاق

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

كيف تفحص التحويل في المتصفح؟

1. افتح أدوات المطور في Chrome، ثم تبويب Network، وفعّل Preserve log للاحتفاظ بالطلبات أثناء الانتقال.
2. افتح الرابط القديم كاملًا، ثم راجع طلب المستند ورمز الحالة في Status.
3. من Headers، راجع وجهة التحويل في Location، ثم تتبع الطلبات حتى العنوان النهائي.
4. تحقق من استجابة الوجهة ومن محتواها الفعلي، لا من تغير شريط العنوان وحده.

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

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

اختبر الوظائف التي تحقق هدف الموقع

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

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

متى تؤجل الإطلاق؟

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

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

متى تستخدم أداة تغيير العنوان في Search Console؟

تُستخدم أداة تغيير العنوان عند الانتقال بين نطاقين أو نطاقين فرعيين، بعد النقل والتحويلات. لا تستخدمها لتغيير الاستضافة فقط، أو المسارات داخل النطاق نفسه، أو الانتقال إلى HTTPS وحده، أو التبديل بين www وبدونها على النطاق نفسه.

يجب أن تكون مالكًا للموقعين بالحساب نفسه. افتح الأداة من خاصية المصدر على مستوى النطاق أو المضيف، لا من خاصية تبدأ بمسار فرعي، وحدد الوجهة واجتز الفحوص المطلوبة. يشمل ذلك خصائص جذرية مناسبة، وليس حصرًا نوع «Domain property».

انتبه إلى فحص التحويلات: تنص وثيقة الأداة على فحص 301 للرئيسية وعينة صفحات؛ لذلك استخدمه في خطة النقل المعتمدة عليها. هذا لا يعني أن 308 غير معترف به تحويلًا دائمًا في بحث Google.

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

أرسل الخريطة الجديدة وافحص الصفحات المهمة

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

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

ماذا عن الخريطة القديمة؟ يتضمن دليل النقل توجيهين مختلفين: خطوة الإطلاق تجيز إزالتها بعد إرسال الجديدة، بينما يصف قسم المتابعة استخدام الخريطتين. عمليًا، اعتمد الجديدة للعناوين المطلوبة واحتفظ بقائمة القديمة للفحص؛ لا تجعل بقاء ملف الخريطة شرطًا لاستمرار التحويلات، ولا تحذف التحويلات عند إزالة الملف.

كم تحتفظ بالدومين القديم والتحويلات؟

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

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

كذلك، حافظ على شهادة HTTPS صالحة للأسماء القديمة التي تستقبل طلبات آمنة. فالاتصال الآمن والتحقق من هوية الخادم يسبقان تبادل استجابة HTTP، كما يشرح مرجع TLS؛ تعطل الشهادة قد يمنع الوصول إلى التحويل أصلًا.

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

كيف تتابع الموقع وتفسّر انخفاض الزيارات بعد النقل؟

قسّم المتابعة إلى التشغيل، والفهرسة، والأداء. لا تستنتج نجاح النقل من انخفاض ظهور الدومين القديم وحده، ولا فشله من هذا الانخفاض؛ قارن ما يحدث للعناوين القديمة بمقابلاتها الجديدة.

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

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

اربط العَرَض بفحص محدد

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

إذا ارتفعت أخطاء الخادم، راجع السجلات والقدرة الاستيعابية قبل انتظار تحسن الفهرسة. توضح وثائق استجابات HTTP أن أخطاء 5xx و429 تؤثر في وتيرة الزحف، وقد تتضرر الفهرسة إذا استمرت المشكلة.

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

كم تستغرق معالجة العناوين الجديدة؟

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

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

متى تعتمد النقل، ومتى تستخدم خطة التراجع؟

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

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

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