يمكن للترحيل أن يمحو سنوات من الترتيب في عطلة نهاية أسبوع واحدة.

ما الذي يتعطل فعليًا أثناء الترحيل

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

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

قبل تغيير أي رابط

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

تحصل على قائمة تحقق للترحيل وإطار موافقة قبل أن يتحرك أي شيء. لا شيء يُطلق بناءً على رأينا وحده.

ما يحدث عند الإطلاق

يُتحقَّق من أكواد التتبع قبل الإطلاق، لا بعده. عند الإطلاق نراقب Search Console وGA4 وAhrefs في الوقت الفعلي، ونتحقق من كل إعادة توجيه، ونعيد إرسال خرائط الموقع، ونصلح أخطاء الزحف فور ظهورها. ويؤكد تدقيق تقني نهائي أن البناء الجديد يتصرف كما كانت النسخة التجريبية.

الـ90 يومًا التالية للإطلاق

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

أنواع الترحيل التي نغطيها

يستخدم الناس كلمة "ترحيل" لأعمال مختلفة عدة، ومستوى المخاطرة ليس واحدًا في كل منها. وفيما يلي كيف نحدد نطاقها.

• تغيير النطاق. الموقع نفسه، عنوان جديد. كل شيء يعتمد على خريطة إعادة التوجيه وسرعة ربط جوجل للعلامة بالمضيف الجديد.
• تغيير المنصة. من ووردبريس إلى Shopify، أو من بناء مخصص إلى ووردبريس، أو من إطار عمل إلى آخر. نادرًا ما تنجو أنماط الروابط سليمة، فيكون عمل الربط هو المهمة كلها.
• إعادة تصميم على النطاق نفسه. قد لا تتغير الروابط إطلاقًا، ومع ذلك ينخفض الترتيب، لأن المحتوى اختُصر، أو حُوِّلت العناوين إلى صور، أو أُسقطت صفحة بصمت من التنقل.
• نقل مجلد فرعي أو نطاق فرعي إلى نطاقه الخاص. الأصعب في المجموعة. أنت تتخلى عن مرجعية النطاق الأصلي وتبدأ مضيفًا جديدًا من الصفر، فيجب أن تحمل خريطة إعادة التوجيه كل إشارة ممكنة.
• الدمج. دمج موقعين أو أكثر في موقع واحد. الخطر ليس إعادة التوجيه، بل تحديد أيّ الصفحتين المتنافستين تبقى.
• تغييرات البروتوكول واسم المضيف. من HTTP إلى HTTPS، ومن www إلى بدونها، ومن شرطة مائلة ختامية إلى بدونها. نطاق صغير، لكنه لا يزال قادرًا على إنتاج فهرسة مكررة إن تعارضت الروابط الأساسية مع إعادة التوجيه.
• تغييرات الخادم والاستضافة. لا تنتقل أي روابط إطلاقًا، ومع ذلك يبقى خطرًا حقيقيًا: أوقات الاستجابة، وشهادة SSL، وهل يُرجع المضيف الجديد حالة 200 نظيفة لزاحف البحث بدلًا من خطأ خفي تحت الضغط.
• الاستعادة. حدث الترحيل بالفعل، وانخفضت الزيارات، ولم يحتفظ أحد بسجل الروابط القديمة. هذا تعاقد مختلف: نعيد بناء البنية القديمة من Search Console والزحف المؤرشف وبيانات الروابط الخلفية، ثم نعيد بناء الخريطة لاحقًا.

ما تحصل عليه فعليًا

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

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

ننفذ ذلك عبر Sitebulb وSemrush وAhrefs وAdvanced Web Ranking وMoz Pro، إلى جانب Search Console وBing Webmaster Tools وGA4. ذكرها هنا مهم: يُحكم على الترحيل ببيانات الزحف، وجودة بيانات الزحف من جودة الزاحف الذي أنتجها.

خطة الترحيل التي ننفذها، مرحلة بمرحلة

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

المرحلة الأولى — قبل تحرك أي شيء

1. منع فهرسة الموقع التجريبي (noindex) (المطور)
2. رفع المحتوى الجديد ومراجعته بالكامل (المطور)
3. إضافة أكواد التتبع والتحليلات وبكسلات الإعلانات واختبارها (الطرفان)
4. نقل التحقق من Search Console إلى البناء الجديد، بالطريقة نفسها التي تم التحقق بها من الملكية (الطرفان)
5. تطبيق بنية الروابط التي نقدمها (المطور)
6. فحص سلامة الموقع الحي الحالي (VOCTOS)
7. تدقيق SEO تقني شامل (VOCTOS)
8. إصلاح ما يكشفه التدقيق، على النسخة التجريبية، قبل الإطلاق (المطور)
9. التأكد من وجود صفحة 404 مخصصة (المطور)
10. أخذ نسخة احتياطية كاملة من الموقع الحالي (الطرفان)
11. التأكد من وجود كل الصفحات المؤسسية: من نحن، تواصل معنا، سياسة الخصوصية، الشروط، خريطة موقع HTML، وإشعار ملفات تعريف الارتباط (الطرفان)
12. تصدير قائمة الروابط الجديدة (المطور)
13. بناء خريطة الروابط، من القديم إلى الجديد، كل صفحة (VOCTOS)
14. إعداد لوحة المراقبة والتقارير (VOCTOS)
15. تسجيل الكلمات المفتاحية التي يحتل الموقع ترتيبًا عليها حاليًا إن لم توجد قائمة (الطرفان)
16. نقل الوسوم الوصفية الحالية إلى البناء الجديد (الطرفان)
17. تفعيل إعادة توجيه 301، لكل الروابط دفعة واحدة لا على دفعات (الطرفان)
18. التعامل مع Google News، إن كان الموقع مسجلًا فيها (الطرفان)

المرحلة الثانية — يوم الإطلاق

1. إرسال كلتا خريطتي الموقع XML، القديمة والجديدة (VOCTOS)
2. تحديث robots.txt (الطرفان)
3. التأكد من عمل التحليلات وSearch Console وTag Manager على البناء الجديد (الطرفان)

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

1. تدقيق تقني في اليوم نفسه، بحثًا عن أخطاء 404 والروابط المعطلة وإعادة التوجيه الداخلي وأي إعادة توجيه ليست 301 (VOCTOS)
2. اختبار السرعة ومؤشرات Core Web Vitals (VOCTOS)
3. اختبار كل إعادة توجيه من القديم إلى الجديد (VOCTOS)
4. إصلاح ما نبلّغ عنه (المطور)
5. تدقيقات ترتيب أسبوعية (VOCTOS)
6. تقديم مجموعة الوسوم الوصفية لكل صفحة: العنوان، الوصف، H1، والرابط الأساسي (VOCTOS)
7. تنفيذها (المطور)
8. مراجعة التنفيذ (VOCTOS)
9. تحديث robots.txt مجددًا بعد استقرار حالة الإطلاق (الطرفان)
10. مراجعة الروابط الداخلية وتشغيل اختبار التوافق مع الجوال (VOCTOS)
11. التحقق من أساسيات الكود مقابل الأدوات المعيارية (الطرفان)
12. إضافة أي صفحات أساسية مفقودة وإشعار ملفات تعريف الارتباط (المطور)
13. التأكد من صحة شهادة SSL وأن كل رابط HTTP يُعاد توجيهه إلى HTTPS (المطور)
14. اختبار الموقع عبر الأجهزة والمتصفحات (الطرفان)
15. التأكد من قابلية فهرسة كل صفحة مهمة، دون وسم noindex عارض، ومع روابط أساسية تشير إلى الوجهة الصحيحة (الطرفان)
16. إزالة الصفحات التي لم يكن ينبغي أن توجد أصلًا من الفهرس (VOCTOS)
17. مراقبة Domain Authority خلال فترة التعافي (VOCTOS)

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