Which condition defines a same-URL hosting migration?

The public scheme, hostname, and path stay identical

All old URLs redirect to the homepage

The CMS must also stay the same

When should DNS TTL usually be lowered for a planned hosting move?

In advance of the move, with enough time for old cached values to expire

Only after the old host is shut down

At launch, after cached answers are already in use

What is the best retirement gate for the old hosting infrastructure?

When its request logs show traffic has reached zero

Twenty-four hours after DNS changes

When the new homepage returns 200 once

Immediately after a cache purge

Why must TLS be tested both at the edge and the origin?

A CDN migration can have separate browser-to-edge and edge-to-origin trust paths

CDNs never use HTTPS to origins

DNS automatically validates certificates

Only asset hostnames use certificates

What should trigger rollback?

A pre-agreed availability, content, security, or capacity failure that cannot be fixed in time

Any temporary Googlebot crawl-rate fluctuation

The first DNS resolver that still has a cached answer

A lower cache hit ratio for one minute

ترحيل استضافة المواقع، CDN و DNS وتحسين محركات البحث

TL;DR — ترحيل الاستضافة ينقل الآلية التي تعمل خلف موقع الويب الخاص بك بينما يستمر الزوار في استخدام نفس عناوين URL. قم ببناء واختبار المضيف الجديد أولاً، واخفض مدة البقاء (TTL) في DNS قبل الإطلاق، وأبقِ المضيف القديم يعمل أثناء التبديل، وقارن ما يعيده كلا النظامين. راقب DNS والشهادات ورموز الحالة والمحتوى والسرعة ووصول الزاحف. أوقف تشغيل المضيف القديم فقط بعد أن تُظهر سجلاته أن حركة المرور وصلت إلى الصفر.

ما هو ترحيل الاستضافة؟

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

بقاء عنوان URL كما هو هو الشرط المحدد. https://example.com/page/ يجب أن يبقى https://example.com/page/ قبل وبعد النقل.

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

لماذا يمكن أن يؤثر نقل بنفس URL على SEO؟

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

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

ما هي الخطوات الأساسية؟

انسخ أو اربط الموقع بالبنية التحتية الجديدة.
اختبر الأصل الجديد وCDN دون تغيير DNS العام.
اخفض TTL في DNS مسبقًا بحيث ينتشر التغيير النهائي بشكل أسرع.
تأكد من الشهادات والتخزين المؤقت وقواعد الأمان ووصول الزاحف.
غيّر DNS لإرسال حركة المرور إلى البنية التحتية الجديدة.
أبقِ كلا البيئتين متصلتين بينما تنتهي صلاحية ذاكرات DNS المؤقتة.
راقب السجلات والأخطاء والسرعة والزحف وأداء البحث.
أوقف تشغيل المضيف القديم فقط عندما تُظهر سجلاته عدم وجود حركة مرور متبقية.

توصي Google بنفس تسلسل التحضير والتبديل والمراقبة والإيقاف في وثائق تغيير الاستضافة.

ماذا يفعل TTL في DNS؟

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

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

هل تحتاج إلى عمليات إعادة توجيه؟

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

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

متى يكتمل النقل؟

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

TL;DR — تعامل مع ترحيل الاستضافة أو CDN أو DNS بنفس عنوان URL كمشروع لتكافؤ الاستجابة وتوجيه حركة المرور. قم بجرد كل اسم مضيف وتبعية، واخفض TTL لنظام DNS قبل الإطلاق، وقم بإعداد الأصل الجديد والحافة، وتحقق من الشهادات وضوابط الأمان، واختبر الحمل بواقعية لطلبات الزاحف والمستخدم، وقارن الاستجابات الخام والمقدمة. قم بتشغيل البنية التحتية القديمة والجديدة بالتوازي خلال انتشار DNS. راقب كلا تدفقي السجلات، وإجابات DNS، والأخطاء، وزمن الاستجابة، وسلوك التخزين المؤقت، ونشاط الزحف، وSearch Console. قم بالتراجع عن طريق استعادة التوجيه السابق فقط عند حدوث فشل في البنية التحتية متفق عليه مسبقًا.

قرر ما إذا كان هذا بالفعل ترحيلًا بنفس عنوان URL

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

صنف المشروع قبل التخطيط له:

التغيير	نقل استضافة بنفس عنوان URL؟	عمل ترحيل إضافي
عنوان IP جديد للأصل، نفس عناوين URL	نعم	تكافؤ الاستجابة، DNS، السعة، السجلات
CDN جديد، نفس عناوين URL	نعم	قواعد الحافة، التخزين المؤقت، TLS، جدار الحماية، توجيه الأصل
مزود DNS موثوق جديد	عادة	تكافؤ المنطقة، التفويض، DNSSEC، سجلات البريد والخدمة
`www.example.com` إلى `example.com`	لا	تعيين عناوين URL وإعادة التوجيه الدائمة
HTTP إلى HTTPS	لا	ترحيل البروتوكول وإعادة التوجيه لكل عنوان URL
تغييرات المسار أو عناوين URL المولدة بواسطة CMS	لا	ترحيل عناوين URL بالإضافة إلى ضمان جودة المنصة

لا تدع مدير المشروع يصف تغيير عنوان URL بأنه “مجرد استضافة.” يجب أن تتضمن خطة النشر كل نوع ترحيل يتم شحنه فعليًا.

بناء جرد البنية التحتية

يمنع جرد البنية التحتية التبعيات الصامتة من أن تصبح مفاجآت يوم الإطلاق. سجل:

جميع أسماء المضيفات العامة، بما في ذلك الأصول والصور وواجهات برمجة التطبيقات والمضيفات الدولية والأسماء المستعارة القديمة؛
سجلات A وAAAA وCNAME وNS وSOA وCAA وMX وTXT وسجلات SRV ذات الصلة؛
جهات إصدار الشهادات وطرق التحقق وأسماء Subject Alternative Names وتواريخ الانتهاء؛
عناوين الأصل والمنافذ وفحوصات الصحة وموازنات التحميل وسلوك تجاوز الفشل؛
مفاتيح التخزين المؤقت لـ CDN وقواعد التخزين المؤقت وعمليات إعادة التوجيه والتحويلات والعمال وطرق المسح؛
قواعد WAF والروبوتات وتحديد المعدل والجغرافيا والمصادقة وقواعد السماح/الرفض لعناوين IP؛
رؤوس الاستجابة والضغط وسلوك ملفات تعريف الارتباط ورؤوس الأمان؛
وجهات السجلات والاحتفاظ وأخذ العينات والحقول والمناطق الزمنية؛
طرق التحقق من Search Console والتحليلات؛
عمليات الاسترجاع من جهات خارجية وخطافات الويب وتدفقات الدفع والخلاصات وعناوين IP المسموح بها.

يجب أن يتضمن مراجعة DNS السجلات غير المتعلقة بالويب. كسر سجلات MX أو SPF أو DKIM أو DMARC أو سجلات الخدمة قد لا يغير الترتيب مباشرة، لكنه قد يكسر العمل الذي كنت تحاول حمايته.

إنشاء خط أساس لتكافؤ الاستجابة

تكافؤ الاستجابة يعني مقارنة النظامين القديم والجديد لنفس عنوان URL المطلوب، وليس مجرد التحقق من أن كلاهما يعيد 200.

التقط مجموعة تمثيلية عبر القوالب والسلوكيات:

الحالة وسلسلة إعادة التوجيه؛
عنوان URL النهائي والتفاوض على البروتوكول؛
العنوان والرابط الأساسي وتوجيهات الروبوتات وhreflang والبيانات المنظمة؛
HTML الخام والمحتوى الرئيسي المقدم بواسطة المتصفح؛
Content-Type وCache-Control وVary والضغط ورؤوس الأمان؛
الصور والخطوط وجافا سكريبت وCSS وPDF ووسائط الأصول؛
ملفات تعريف الارتباط والمتغيرات المخصصة أو المسجلة الدخول؛
سلوك الجوال وسطح المكتب؛
زمن الاستجابة ووقت أول بايت ومعدل الخطأ.

استخدم Staging vs. Production SEO Diff لفحوصات الصفحات المقترنة. يجب أن يغطي زاحف كامل ومجموعة طلبات نصية الجرد الأكبر.

تحضير الأصل الجديد

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

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

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

تكوين CDN كنظام منفصل

تغيير CDN يؤثر على أكثر من الجغرافيا. قارن سلوك الحافة القديم والجديد بشكل صريح:

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

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

تعامل مع تكافؤ التخزين المؤقت كتكافؤ محتوى

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

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

التحقق من TLS من المستخدم إلى الحافة ومن الحافة إلى الأصل

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

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

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

خفض TTL لنظام DNS قبل النقل

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

توثق وثائق TTL الخاصة بـ Cloudflare المفاضلة الأساسية: القيم الأطول تزيد من إعادة استخدام التخزين المؤقت، بينما تسمح القيم الأقصر بتطبيق تغييرات السجلات بشكل أسرع. سجل TTL الأصلي وجدول استعادته فقط بعد استقرار البنية التحتية الجديدة.

يمكن أن تكون تغييرات DNS غير ذرية عبر الأنظمة الموزعة. غيّر أقل قدر ممكن أثناء القطع، وتحقق من الإجابات من عدة محللات عامة، وأبقِ الوجهة القديمة متاحة بينما تظل الإجابات المخزنة مؤقتًا صالحة.

التحقق من وصول الزاحف وضوابط الأمان

التكافؤ الأمني ليس تكافؤ عدد القواعد. يمكن لجدار حماية تطبيقات الويب (WAF) منسوخ من مزود آخر أن يتحدى أو يحظر الزواحف، أو يزيل معلمات الاستعلام، أو يعيد كتابة الاستجابات، أو يحد من معدل الزحف العالي بشكل مختلف.

يقول دليل الاستضافة من Google إنه يجب ضمان عدم حظر جدران الحماية وحماية رفض الخدمة لـ Googlebot من خوادم DNS أو الاستضافة. تحقق من Googlebot باستخدام طرق التحقق الموثقة من Google، وليس فقط سلسلة وكيل المستخدم.

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

تخطيط التشغيل المزدوج

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

اختر استراتيجية مزامنة:

قاعدة بيانات قراءة/كتابة واحدة مشتركة بين المجموعتين؛
بيانات مكررة مع فهم التأخير وسياسة التعارض؛
تجميد محتوى خاضع للتحكم أثناء القطع؛
تكرار الأحداث في اتجاه واحد للطلبات أو النماذج أو كتابات المستخدم.

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

The old environment is a rollback path only while it remains valid and synchronized. Retirement begins when logs prove the old path is no longer used. المصدر: Website Hosting Migration SEO

Prepare builds the new origin and edge path. Validate tests controlled routing, parity, certificates, and capacity. Dual run keeps old and new environments correct and synchronized. Cut over changes only the planned DNS or edge route. Drain observes old-host requests in separate logs while the old environment remains available. Retire occurs only when old-host traffic reaches zero and dependencies have moved. A rollback lane remains available before retirement when a pre-agreed infrastructure failure occurs and the old state is still valid.

تنفيذ القطع

يجب أن يكون قطع الاستضافة مملاً عمدًا:

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

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

مراقبة الأدلة التي تثبت النقل

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

راقب:

إجابات DNS وانتشار المحلل؛
طلبات المضيف القديم والجديد من المستخدمين والزواحف الموثقة؛
توزيع رموز حالة الحافة والأصل؛
أخطاء TLS والاتصال والمهلة والتطبيق؛
نسب زمن الاستجابة ووقت استجابة الأصل غير المخزن مؤقتًا؛
نسبة النجاح في التخزين المؤقت وحجم طلبات الأصل؛
طلبات Googlebot وإحصائيات الزحف وفهرسة الصفحات وفحص عناوين URL التمثيلي؛
فحوصات اصطناعية عبر المناطق والشبكات؛
التحليلات والتحويلات والمعاملات التجارية الحرجة.

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

تحديد التراجع قبل الإطلاق

يعيد التراجع التوجيه إلى حالة بنية تحتية معروفة جيدة. ليس وعدًا غامضًا بـ “إعادة تبديل DNS”. وثّق:

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

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

تقاعد البنية التحتية القديمة بناءً على السجلات، وليس التقويم

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

احتفظ بتصديرات التكوين والسجلات وقطع أثر التراجع وفقًا لمتطلبات العمل. أعد ضبط TTL لنظام أسماء النطاقات (DNS) إلى القيمة الثابتة المقصودة بعد إثبات الاستقرار. أزل استثناءات جدار الحماية المؤقتة والمهام المجدولة المكررة حتى لا يترك الترحيل فوضى صيانة دائمة.

A same-URL hosting migration is an availability and response-parity program. Fund overlap between old and new infrastructure, measurable launch gates, and an executable rollback.

Dual running buys time for DNS propagation and lets the team reverse routing without rebuilding the old environment.
A response-parity baseline turns launch debates into testable pass/fail decisions.
Old-host and new-host logs show whether the move is actually complete; the project should not retire infrastructure on an arbitrary date.

Search and revenue continuity

The public URLs remain stable, but DNS, TLS, caching, security, capacity, or content differences can still make the site unavailable or materially different to users and crawlers.

0

Public URL changes

Traffic reaches zero

Old-host retirement gate

Dual run + rollback

Launch posture

الخطر عند التجاهل: A DNS or CDN switch can create outages, stale or personalized cache leaks, crawler blocks, and lost measurement even when every URL appears unchanged.

اسأل فريقك: Can we prove response parity, handle uncached launch load, observe both environments, and restore the previous route inside the approved recovery time?

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

ترحيل الاستضافة يغير الخوادم أو CDN أو الأصل أو DNS بينما تظل عناوين URL العامة متطابقة.
تغييرات URL تتطلب عملية نقل الموقع الأوسع. النقل الحقيقي للمضيف فقط لا يحتاج إلى خريطة إعادة توجيه جديدة أو تقديم تغيير العنوان.
قم بجرد DNS وTLS والأصل وCDN وWAF وذاكرة التخزين المؤقت والسجلات والتحقق والأصول والتبعيات التجارية قبل الإطلاق.
اخفض TTL لنظام DNS قبل القطع، واحتفظ بالقيمة القديمة، وأعدها بعد استقرار المسار الجديد.
قارن بين الاستجابات الأولية القديمة والجديدة، والصفحات المعروضة، والترويسات، والأصول، وعمليات إعادة التوجيه، ورموز الحالة، وزمن الاستجابة، والسلوك التجاري.
تحقق من TLS من المتصفح إلى الحافة ومن الحافة إلى الأصل، بالإضافة إلى الشهادات على أي مسار تراجع.
قم بتشغيل البيئتين بشكل مزدوج وقم بمزامنة الكتابات حتى تتوقف إجابات DNS المخزنة مؤقتًا عن إرسال حركة المرور إلى المكدس القديم.
راقب كلا تدفقي السجلات، وإجابات DNS، والأخطاء، وتحميل الأصل، وسلوك ذاكرة التخزين المؤقت، ووصول الزاحف الموثق، وSearch Console، والتحويلات.
قم بتقاعد المضيف القديم فقط عندما تُظهر سجلاته أن حركة المرور وصلت إلى الصفر.

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

Google

تغيير استضافة الويب وتحسين محركات البحث يشرح عملية التحضير بنفس عنوان URL، وتبديل DNS، والمراقبة، والإيقاف.
نقل المواقع مع تغييرات URL ينطبق عندما يتغير المخطط أو اسم المضيف أو المسار أيضًا.
التحقق من Googlebot يوثق التحقق من DNS العكسي/الأمامي وعناوين IP المنشورة.
تقرير إحصائيات الزحف يساعد في مراقبة طلبات Googlebot وتوفر المضيف.

مراجع البنية التحتية

Cloudflare DNS TTL يشرح TTL ومقايضات الانتشار.
Cloudflare cache يوثق التخزين المؤقت للحافة، وقواعد التخزين المؤقت، والتطهير.
Cloudflare Origin CA يوثق شهادات الحافة إلى الأصل وقيود ثقة المتصفح.

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

“This guide is only for migrations that don’t affect the user-visible URL.” (ترجمة) «هذا الدليل مخصص فقط للترحيلات التي لا تؤثر على عنوان URL الظاهر للمستخدم.» Google Search Central. الانتقال إلى دليل الاستضافة
إعادة الصياغة: توصي Google بخفض TTL لنظام DNS قبل النقل، وضمان أن جدران الحماية لا تزال تسمح بحركة مرور Googlebot الموثوقة، وتوقع انخفاض مؤقت في معدل الزحف، وإبقاء المضيف القديم متاحًا حتى تنتهي حركة المرور إليه. إرشادات TTL, إرشادات جدار الحماية, إرشادات معدل الزحف, وإرشادات الإيقاف.

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

النطاق والخط الأساسي

تأكد من عدم تغيير أي عنوان URL عام.
حصر جميع أسماء المضيفين للويب والأصول وAPI والإقليمية.
صدّر تكوينات DNS وCDN وWAF وذاكرة التخزين المؤقت وإعادة التوجيه وTLS والأصل.
حفظ خطوط أساسية ممثلة للاستجابات الأولية والمقدمة.
سجل خطوط الأساس لحركة المرور والأخطاء وزمن الاستجابة والزحف والفهرسة والتحويلات.

البنية التحتية الجديدة

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

DNS والإطلاق

خفض TTLs ذات الصلة قبل النقل وتسجيل القيم الأصلية.
الحفاظ على السجلات غير الخاصة بالويب وDNSSEC والتحقق وتبعيات الخدمة.
توثيق تغيير التوجيه الدقيق وأوامر التراجع.
إبقاء البنية التحتية القديمة والجديدة نشطة مع خطة مزامنة البيانات.
إزالة أي حظر مؤقت للزحف أو الوصول في مسار الإنتاج.
التحقق من إجابات DNS عبر عدة محللات مستقلة.

بعد الإطلاق

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

إطار التكافؤ عبر خمس طبقات

الطبقة	ما يجب أن يظل مكافئًا	ما يثبت ذلك
التوجيه	تصل إجابات DNS في النهاية إلى المسار الجديد المقصود	فحوصات متعددة الحلّات وسجلات قديمة/جديدة
النقل	TLS، وإصدارات HTTP، والشهادات، والاتصال تعمل	طلبات اصطناعية واختبارات الشهادات
الاستجابة	الحالة، وعمليات إعادة التوجيه، والترويسات، وHTML، والأصول تطابق القصد	زحف مقترن وفرق الترويسات
التطبيق	العرض، والجلسات، والنماذج، وواجهات API، والبيانات صحيحة	اختبار المتصفح واختبارات المعاملات
الاكتشاف	تصل الزواحف الموثوقة إلى الموقع وتعالجه بشكل طبيعي	سجلات الوصول، وإحصائيات الزحف، وفحص URL

Each infrastructure layer can pass or fail independently. A fast response or valid certificate proves only one part of the same-URL migration. المصدر: Website Hosting Migration SEO

Routing compares DNS answers and their intended paths using multi-resolver checks and old-versus-new logs. Transport compares TLS, HTTP versions, certificates, and connectivity with synthetic and certificate tests. Response compares status codes, redirects, headers, HTML, and assets with paired crawls and header diffs. Application compares rendering, sessions, forms, APIs, and data with browser and transaction tests. Discovery compares verified crawler access and processing with access logs, Crawl Stats, and URL Inspection. One passing layer does not prove full parity.

نموذج حالة الترحيل

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

لا تسمِّ المشروع مكتملًا عند “تغيير DNS”. هذه بداية التبديل، وليس نهاية الترحيل.

أي خطة ترحيل تنطبق؟

Classify the infrastructure change

إخفاقات ترحيل الاستضافة الشائعة

بعض المناطق لا تزال تصل إلى المضيف القديم

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

تنخفض طلبات Googlebot بعد الإطلاق

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

الصفحات سريعة ولكنها تعرض محتوى قديمًا

السبب المحتمل: TTL للحافة، أو مفتاح ذاكرة تخزين مؤقت، أو فشل تطهير، أو مصدر بيانات متباين. الإصلاح: افحص ترويسات Age وCache-Control وVary وترويسات حالة ذاكرة التخزين المؤقت للمزود؛ واختبر المتغيرات ذات المعنى؛ وقم بالتطهير بشكل ضيق؛ ثم تحقق من الأصل والحافة بشكل منفصل.

الموقع يعمل عبر CDN لكنه يفشل عند تجاوزه

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

تفشل الأصول بينما يعمل HTML

السبب المحتمل: أسماء مضيفات أصول محذوفة، أو CORS، أو شهادات، أو عناوين URL مطلقة، أو قواعد ذاكرة تخزين مؤقت، أو حماية من الروابط الساخنة، أو أذونات الأصل. الإصلاح: قم بالزحف واختبار المتصفح لجرد الأصول، بما في ذلك الخطوط والصور وCSS وJavaScript وPDF والوسائط.

ارتفاع حمل الأصل فورًا

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

أدوات لنقل البنية التحتية بنفس عنوان URL

DNS Checker يقارن أنواع السجلات الشائعة عبر عدة محللات عامة. استخدمه أثناء الانتشار، لكن قارن النتيجة مع المنطقة الموثوقة أيضًا.
HTTP Header Checker يعرض الترويسات عبر عمليات إعادة التوجيه، بما في ذلك بصمات CDN، والضغط، والأمان، وعناصر التحكم في التخزين المؤقت.
Staging vs. Production SEO Diff يقارن عناوين URL المقترنة عبر الحالة، والكنونيكالات، والتوجيهات، والترويسات المحددة، والمخطط، و المحتوى.
Bulk HTTP Status Code Checker يتحقق من الحالة، وإعادة التوجيه، والوجهة، وزمن الاستجابة عبر مجموعة عناوين URL تمثيلية.
Google Index Checker يتحقق من عوائق الزحف و الفهرسة الملحوظة، ثم يوجهك إلى Search Console لعرض جوجل الخاص.
سجلات الخادم والحافة تثبت أين ذهب الزيارات، وما الاستجابة التي تلقتها، و متى تكون البنية التحتية القديمة غير مستخدمة فعليًا.
المراقبة الاصطناعية تختبر التوفر العام والمعاملات الحرجة من عدة شبكات ومناطق.

إثبات نجاح ترحيل الاستضافة

اختبار انتشار DNS واستنزاف المضيف القديم

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

اختبار تكافؤ الاستجابة

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

اختبار وصول الزاحف والسعة

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

اختبار أمان التخزين المؤقت

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

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

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

A Website Migration Takes More Than a Checklist to Be Successful يغطي عملية الترحيل الأوسع، والخطوط الأساسية، والمراحل، والمراقبة.
Redirects for SEO يشرح سلوك إعادة التوجيه القديم الذي يجب أن يبقى بعد نقل البنية التحتية.

أدلة ذات صلة في هذا الموقع

Site Migrations يغطي تصنيف الترحيل و العملية العامة.
Website Migration Checklist يوفر قائمة التحقق القائمة على المراحل.
HTTP Status Codes يشرح طبقة الاستجابة التي يجب أن تحافظ عليها وتراقبها.

من حول الصناعة

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

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