قائمة تحقق لترحيل الموقع: حافظ على ترتيبك في البحث وبريدك وبيانات التتبّع

حدّد ما الذي يتغيّر فعلًا

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

• تغيير النطاق، مثل الانتقال من example.co.il إلى example.com.
• تغيير المنصة، مثل الانتقال من WordPress إلى Next.js أو من منصة متجر إلى أخرى.
• تغيير بنية الروابط: مسارات جديدة، أو مستويات تصنيف جديدة، أو إزالة مجلدات اللغات.
• تغيير الاستضافة أو الخادم مع بقاء النطاق والروابط كما هي.
• تغيير البروتوكول أو المضيف: من HTTP إلى HTTPS، أو من www إلى العنوان دون www.
• دمج عدة مواقع في موقع واحد، أو تقسيم موقع إلى عدة مواقع.

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

اجرد كل رابط مهم

لا تكون خريطة التحويلات أدق من القائمة التي تستند إليها، لذلك ابنِ القائمة من عدة مصادر، فكل مصدر يغفل شيئًا:

• افحص الموقع الحالي بأداة زحف. تعطيك أداة زحف مثل Screaming Frog أو Sitebulb كل صفحة يصل إليها رابط، مع رمز حالتها والرابط القانوني (canonical) والعنوان.
• صدّر البيانات من Search Console. يعرض تقرير الصفحات ما فهرسته Google، ويعطيك تقرير الأداء النقرات ومرات الظهور لكل صفحة لفترة تصل إلى 16 شهرًا. ولأن الواجهة لا تصدّر أكثر من 1,000 صف، اسحب البيانات في المواقع الكبيرة عبر Search Console API أو موصل Looker Studio أو التصدير المجمّع إلى BigQuery.
• صدّر صفحات الهبوط من أداة التحليلات. صفحات الهبوط في GA4 على مدى اثني عشر شهرًا تكشف صفحات الحملات والصفحات القديمة التي لم تعد في القائمة.
• اجمع الصفحات التي لها روابط خارجية. يُظهر تقرير الروابط في Search Console، أو أداة لتحليل الروابط، الصفحات التي تشير إليها مواقع أخرى.
• أضف الملفات والوسائط. ملفات PDF والصور والتنزيلات التي تحصل على زيارات أو روابط تحتاج إلى تحويلات أيضًا.

اجمع كل شيء في جدول واحد، واحذف المكرر، وسجّل أمام كل رابط زياراته والروابط التي تشير إليه. هذا العمود هو ما يدلّك على التحويلات التي لا تحتمل الخطأ.

ابنِ خريطة تحويلات 301

كل رابط قديم له زيارات أو روابط خارجية أو مفهرس لدى محركات البحث يحصل على تحويل دائم (301) إلى أقرب صفحة جديدة تقابله.

• حوّل إلى الصفحة المقابلة، فتحويل صفحات كثيرة إلى الصفحة الرئيسية يُعامَل عادةً على أنه خطأ 404 مخفي (soft 404)، ويضيع معه الترتيب القديم.
• قفزة واحدة فقط. حدّث التحويلات الموجودة كي تشير الروابط القديمة مباشرة إلى العنوان النهائي، بدل أن تمر بعنوان وسيط.
• اختر صيغة واحدة للشرطة المائلة في آخر الرابط ولحالة الأحرف ولمضيف www، وحوّل كل صيغة أخرى إليها.
• الصفحات التي لا مقابل لها ولا قيمة يجب أن تعيد 404 أو 410، لا أن تُحوَّل إلى صفحة لا علاقة لها بها.
• نفّذ التحويلات على الخادم أو على الحافة (Nginx أو ‎.htaccess أو قواعد Cloudflare أو إعدادات إطار العمل)، وليس عبر JavaScript أو meta refresh.

أبقِ بيئة الاختبار خارج الفهرسة

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

• احمِ بيئة الاختبار بكلمة مرور (HTTP basic authentication) أو بقائمة عناوين IP مسموح بها، فهذا هو الحجب الوحيد الموثوق.
• أضف ترويسة X-Robots-Tag: noindex طبقةً ثانية، فقاعدة Disallow في robots.txt وحدها لا تمنع فهرسة الروابط إذا ذُكرت في أماكن أخرى.
• أدرج إزالة كل أشكال الحجب في قائمة الإطلاق، فبقاء noindex أو «Disallow: /» على الموقع الفعلي من أكثر أخطاء يوم الإطلاق شيوعًا.

X-Robots-Tag: noindex

User-agent: *
Disallow: /

انقل ما تقرؤه محركات البحث

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

• المحتوى. العناوين وأوصاف الميتا وعناوين H1 ونصوص الصفحات الأهم. وحذف المحتوى يُفقدك الترتيب الذي حققه.
• وسوم canonical. تشير إلى الروابط الجديدة على الموقع الفعلي، لا إلى بيئة الاختبار ولا إلى النطاق القديم.
• ‏hreflang. تشير كل نسخة لغوية إلى نفسها وإلى سائر النسخ بروابط كاملة على النطاق الجديد، وهذا ما ينكسر بسهولة في المواقع العربية والعبرية والإنجليزية.
• البيانات المنظّمة. انقل Organization وProduct وBreadcrumbList وغيرها إلى الموقع الجديد، وتحقق منها في Rich Results Test.
• الروابط الداخلية. القوائم والتذييل والروابط داخل النص تستخدم الروابط النهائية، فلا يعتمد الموقع على تحويلاته.
• خريطة موقع XML. لا تضم إلا الروابط النهائية القابلة للفهرسة التي تعيد الرمز 200.

جهّز DNS وSSL قبل الانتقال

• احصل على الصلاحيات مبكرًا. اعرف من يتحكم في حساب مسجّل النطاق ومزوّد DNS، وتأكد قبل أسبوع الإطلاق بوقت كافٍ من أن بيانات الدخول تعمل.
• صدّر المنطقة (zone). احفظ نسخة كاملة من سجلات DNS الحالية قبل أن تلمس أي شيء.
• تغيير مزوّد DNS. إذا كانت المنطقة نفسها ستنتقل إلى مزوّد DNS جديد، فأعد إنشاءها كاملة هناك، وقارنها سجلًا سجلًا، وبدّل خوادم الأسماء (nameservers) لدى المسجّل قبل الانتقال بأيام، لأن سجلات NS في المنطقة الأم كثيرًا ما تكون مدة TTL فيها 48 ساعة ولا يمكنك خفضها. بعد ذلك نفّذ تغيير الموقع كأي تعديل عادي في السجلات.
• خفّض قيمة TTL. خفّض TTL للسجلات التي ستغيّرها إلى نحو 300 ثانية، قبل الانتقال بمدة TTL القديمة كاملة على الأقل (غالبًا 24 إلى 48 ساعة)، فينتشر التغيير سريعًا ويمكن التراجع عنه سريعًا.
• أصدر الشهادات أولًا. يجب أن تكون على الخادم الجديد أو شبكة CDN شهادات صالحة لكل اسم مضيف، للنطاق الأساسي ولـ www، قبل أن تصل الزيارات. استخدم التحقق عبر DNS أو شهادة الـ CDN كي يعمل HTTPS من الطلب الأول.
• افحص HSTS. إذا كان الموقع القديم يرسل ترويسة HSTS، فسترفض المتصفحات اتصالات HTTP العادية على أسماء المضيف المشمولة بها، ولذلك يحتاج كلٌّ منها إلى HTTPS يعمل على الخادم الجديد.

لا تمسّ البريد الإلكتروني

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

• انسخ سجلات MX كما هي تمامًا، مع أولوياتها.
• انسخ سجلات SPF وDKIM وDMARC (من نوع TXT وCNAME)، فمن دون SPF أو DKIM تذهب الرسائل إلى البريد العشوائي أو تُرفض.
• أبقِ سجلات TXT التي تتحقق بها Google Workspace وMicrosoft 365 وMeta وغيرها.
• إذا كان الخادم الجديد يرسل رسائل (إشعارات النماذج، تأكيدات الطلبات)، فأرسلها عبر خدمة SMTP موثّقة، وفعّل توقيع DKIM لهذه الخدمة وأضفها إلى سجل SPF. يسمح SPF بعشر عمليات بحث DNS كحد أقصى، فافحص السجل بعد كل include جديد.
• بعد الانتقال، أرسل رسائل اختبار إلى Gmail وOutlook وتحقق في الترويسات من نجاح SPF وDKIM وDMARC.

تحقق من النماذج والتتبع والتحويلات

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

• كل نموذج يُرسَل بنجاح، ويصل الإشعار، ويبلغ العميل المحتمل نظام CRM أو أي وجهة مقررة له.
• وسم GA4 أو حاوية GTM موجودان في كل قالب بمعرّف القياس نفسه، والأحداث الرئيسية تُسجَّل. تحقق من ذلك في Realtime أو DebugView.
• تحويلات Google Ads وبكسل Meta تعمل في الصفحات الصحيحة، ولافتة الموافقة ما زالت تتحكم بها.
• في المتاجر: طلب اختبار كامل عبر صفحة الدفع، مع تحديث روابط الاستدعاء (callback) لبوابة الدفع إلى النطاق الجديد.
• التكاملات التي كُتبت روابطها مباشرة في الشيفرة تواصل العمل: webhooks واستدعاءات API وروابط إعادة التوجيه في OAuth.

يوم الإطلاق

• جمّد المحتوى أو زامنه. أوقف التعديلات على الموقع القديم، أو خطّط لمزامنة أخيرة. وفي المتاجر، زامن الطلبات والعملاء في النهاية.
• خذ نسخة احتياطية جديدة. ملفات الموقع القديم وقاعدة بياناته، محفوظة في مكان تستطيع الاستعادة منه بسرعة.
• بدّل DNS. ثم تأكد من أن الخادم الجديد يستجيب من أكثر من شبكة.
• أزل حجب بيئة الاختبار. ترويسات noindex وقواعد robots.txt وكلمة المرور.
• اختبر خريطة التحويلات. مرّر القائمة الكاملة للروابط القديمة على أداة زحف، وتأكد أن كل رابط يعيد تحويل 301 واحدًا إلى صفحة تعيد 200.
• أرسل خريطة الموقع. أرسلها في Search Console. وإن غيّرت النطاق، فتحقق من ملكية الخاصيتين واستخدم أداة تغيير العنوان (Change of Address).
• أبقِ الخادم القديم يعمل. اتركه يعمل حتى ينتشر DNS بالكامل ولا يعود يصل إليه أي شيء.

الأسابيع التي تلي الإطلاق

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

• في Search Console، راقب في تقرير الصفحات حالتي «غير موجودة (404)» و«صفحة تتضمّن إعادة توجيه»، وتابع عدد الروابط الجديدة المفهرسة.
• افحص سجلات الخادم أو Cloudflare بحثًا عن أخطاء 404 التي يصادفها الزوار الحقيقيون والروبوتات، وأضف تحويلات لكل ما له زيارات أو روابط.
• قارن الزيارات العضوية لكل صفحة هبوط مع قائمة الجرد، لا المجموع العام للموقع فقط.
• راقب مؤشرات Core Web Vitals وأزمنة استجابة الخادم على البيئة الجديدة.
• أبقِ التحويلات قائمة على الدوام. توصي Google بإبقائها سنة على الأقل، والروابط في المواقع الأخرى تظل تشير إلى العناوين القديمة مدة أطول بكثير.

دورنا

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

• SEOSEO تقني وبيانات منظّمة وظهور في البحث
• تطوير المواقعمواقع الشركات والبوابات ومحركات الحجز
• مواقع مُدارةالتحديثات والنسخ الاحتياطي والإصلاحات والدعم