الانتقال من HTTP إلى HTTPS

الخلاصة — الانتقال من HTTP إلى HTTPS يعني نقل كل صفحة على موقعك من العنوان غير الآمن http:// إلى العنوان الآمن https://. تقوم بتثبيت شهادة، ثم تعيد توجيه كل عنوان URL قديم إلى نسخته الآمنة الجديدة حتى لا ينكسر شيء ولا تُفقد أي ترتيبات. إذا تم بحذر فهو آمن — الضرر يأتي فقط من التنفيذ السيئ.

ما الذي تفعله فعليًا

نقل عناوين URL من HTTP إلى HTTPS يغيّر عناوينها الأساسية (canonical URLs) ويجب أن يستخدم عمليات إعادة توجيه دائمة من جانب الخادم بالإضافة إلى إشارات أساسية (canonical signals) متسقة. Evidence for this claim Primary standard or official documentation supporting the adjacent article claim. Scope: Protocol semantics and Search behavior are kept separate; no indexing, ranking, or migration-timing guarantee is inferred. Confidence: high · Verified: 2026-07-14 Google: Site moves with URL changes يجب أيضًا أن يقدم تكوين HTTPS شهادة TLS صالحة ويتجنب الموارد المختلطة. Evidence for this claim Primary standard or official documentation supporting the adjacent article claim. Scope: Protocol semantics and Search behavior are kept separate; no indexing, ranking, or migration-timing guarantee is inferred. Confidence: high · Verified: 2026-07-14 Google: HTTPS

حاليًا، صفحاتك موجودة على عناوين تبدأ بـ http://. تريد أن تكون على https:// بدلاً من ذلك — النسخة الآمنة والمشفرة، التي تُظهر رمز القفل ولا تُطلق تحذير Chrome “Not Secure”. المحتوى، وأسماء النطاقات، والمسارات، وسلاسل الاستعلام تبقى كما هي، ولا تقوم بتغيير نظام إدارة المحتوى أو منصة الاستضافة في نفس الوقت. فقط الأحرف القليلة الأولى من كل عنوان URL تتغير.

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

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

أعد توجيه كل عنوان http:// قديم إلى نسخته https:// المطابقة تمامًا باستخدام إعادة توجيه 301. إعادة التوجيه 301 هي إعادة توجيه “دائمة” — تخبر محركات البحث “هذه الصفحة تعيش هنا الآن، إلى الأبد، من فضلك انقل كل شيء إليها.” أكدت Google أن إعادة التوجيه 301 لا تكلفك أي قوة ترتيب، لذا فإن التحول النظيف يحافظ على حركة المرور الخاصة بك.

تبدأ المشاكل عندما تكون عمليات إعادة التوجيه مفقودة، أو عندما تحاول صفحاتك تحميل صورة أو برنامج نصي من العنوان القديم http://. هذا “المحتوى المختلط” يمكن أن يجعل أجزاء من صفحتك تنكسر في المتصفح. لذا فإن العمل ليس في التحول — بل في التأكد من أن لا شيء لا يزال يشير إلى العناوين القديمة.

النسخة المختصرة من العملية

1. خذ لقطة لموقعك كما هو الآن — قائمة كاملة بالصفحات و ترتيباتك الحالية — حتى تتمكن من المقارنة لاحقًا.
2. احصل على شهادة وقم بتثبيتها. شهادة مجانية (مثل Let’s Encrypt) تعمل بشكل مثالي لتحسين محركات البحث (SEO).
3. اختبر على نسخة أولاً إذا استطعت، حتى لا يكون يوم الإطلاق مفاجئًا.
4. فعّلها: أعد توجيه كل عنوان URL قديم إلى النسخة الآمنة، وحدّث روابطك الداخلية وملف sitemap، وأصلح أي شيء لا يزال يُحمَّل عبر http://.
5. أعد فحص Search Console. الحل الأبسط هو خاصية النطاق (Domain property)، والتي تغطي كل متغيرات http/https/www تلقائيًا — لا تحتاج إلى التحقق من كل واحد على حدة.
6. أبقِ عمليات إعادة التوجيه (لمدة عام على الأقل، ومن الأفضل إلى الأبد) وراقب حركة المرور الخاصة بك لبضعة أسابيع. التذبذب الطفيف أمر طبيعي.

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

هل تريد النسخة الهندسية الكاملة — خيارات الشهادات، ورسم خرائط إعادة التوجيه لآلاف عناوين URL، وخصائص Search Console الأربعة، ونوافذ المراقبة، وخطة التراجع؟ انتقل إلى علامة التبويب متقدم. (لمعرفة مكان HTTPS كإشارة ترتيب في المقام الأول، ابدأ من مركز HTTPS.)

الخلاصة — الانتقال من HTTP إلى HTTPS هو ترحيل موقع يعتمد على البروتوكول فقط: نفس المضيف، والمسارات، وسلاسل الاستعلام، والمحتوى، والمنصة — فقط المخطط يتغير. هذا يجعله الترحيل الأقل خطورة على الإطلاق إذا تحقق كل ذلك — لكن الانضباط مطابق لأي نقل موقع. قم بقياس موقع HTTP المباشر، واختر وقم بتثبيت شهادة TLS (شهادة DV مجانية تكسب نفس إشارة التصنيف الخفيفة مثل أي شهادة مدفوعة — جوجل تتحقق من المخطط، وليس المُصدر)، وتدرب على بيئة تجريبية، ثم انقل: قم بإعادة توجيه 301 لكل عنوان URL واحد لواحد على الخادم (301 لا تفقد PageRank)، واجعل كل صفحة ذاتية canonical إلى عنوان HTTPS الخاص بها، وأعد توجيه كل رابط داخلي، وإدخال sitemap، وتعليق hreflang، وقم بإزالة المحتوى المختلط القابل للحظر قبل أن يكسر نصوصك البرمجية. أضف خاصية Domain في Search Console (وهي تغطي كل متغيرات المخطط/المضيف دفعة واحدة) أو تحقق من خصائص HTTPS بشكل فردي إذا كنت تريد بيانات مجزأة، وأرسل sitemap الخاص بـ HTTPS، ولا تلمس أداة Change of Address — فهي لنقل النطاقات. أبقِ عمليات إعادة التوجيه لمدة عام على الأقل (هذا حد أدنى، وليس تاريخ انتهاء صلاحية). راقب Crawl Stats و الفهرسة: الانخفاض الذي يتعافى هو استقرار النقل؛ والانخفاض المستمر يعني أن شيئًا ما انكسر. ضع خطة تراجع، لكن أصلح HTTPS أولاً — التخزين المؤقت، وHSTS، وملفات تعريف الارتباط، وعمال الخدمة يمكن أن تجعل التراجع الحقيقي إلى HTTP غير آمن — وتعامل مع HSTS preload على أنه بطيء ومحفوف بالمخاطر تشغيليًا للتراجع، وليس بابًا أحادي الاتجاه حرفيًا.

يغطي مركز HTTPS لماذا يجب أن تكون على HTTPS ويحدد الترحيل على مستوى عالٍ. هذا هو الدليل العميق خطوة بخطوة لذلك القسم — الجزء الذي يمكن أن يحدث فيه الترحيل بشكل خاطئ أو بشكل نظيف.

أولاً، قيّم المخاطر بشكل صحيح: هذا ترحيل يعتمد على البروتوكول فقط

تتعامل جوجل مع تغييرات البروتوكول على أنها نقل موقع مع تغييرات في عناوين URL؛ وقد تحدث تقلبات مؤقتة في التصنيف أو التقارير ولا يوجد جدول زمني مضمون لأي ترحيل. Evidence for this claim Primary standard or official documentation supporting the adjacent article claim. Scope: Protocol semantics and Search behavior are kept separate; no indexing, ranking, or migration-timing guarantee is inferred. Confidence: high · Verified: 2026-07-14 Google: Site moves with URL changes أمان النقل ومعالجة البحث مرتبطان لكنهما مخاوف منفصلة. Evidence for this claim Primary standard or official documentation supporting the adjacent article claim. Scope: Protocol semantics and Search behavior are kept separate; no indexing, ranking, or migration-timing guarantee is inferred. Confidence: high · Verified: 2026-07-14 Google: HTTPS

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

• أسماء المضيفين — لا يوجد دمج www/غير www أو تغييرات في النطاقات الفرعية مصاحبة للتبديل.
• المسارات وسلاسل الاستعلام — لا إعادة هيكلة لعناوين URL، أو إعادة تسمية slugs، أو تنظيف المعلمات مدمجة في نفس الإصدار.
• المحتوى — لا تتم إعادة كتابة الصفحات أو دمجها أو اقتطاعها في نفس الوقت.
• سلوك المنصة/العرض — لا يوجد ترحيل CMS أو إطار عمل أو استضافة يحدث بالتوازي.

عندما تتحقق هذه الشروط الأربعة، يكون النطاق والمسارات والمحتوى متطابقة؛ فقط المخطط أمام كل عنوان URL يتحرك. لهذا السبب تؤكد جوجل صراحة أنك “لا تحتاج إلى استخدام أداة Change of Address” لذلك: لا يوجد تغيير عنوان لإعلانه.

النتيجة الأكثر أهمية: نظرًا لأن عناوين URL تتطابق واحد لواحد وبشكل حتمي (http://example.com/x → https://example.com/x)، يمكن أن يكون منطق إعادة التوجيه الخاص بك عادةً قاعدة خادم واحدة، وتكتب خريطة إعادة التوجيه نفسها بنفسها. قارن ذلك بنقل نطاق أو منصة، حيث يحتاج كل عنوان URL قديم إلى وجهة مدققة يدويًا. حافظ على هذا الإطار — فهو يخبرك أين تبذل الجهد (الشهادة، المحتوى المختلط، Search Console) وأين لا (القلق بشأن أهداف إعادة التوجيه).

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

الخطوة 1 — قم بقياس موقع HTTP المباشر قبل لمس أي شيء

لا يمكنك معرفة ما إذا كان الانتقال ناجحًا دون صورة “قبل” للمقارنة بها. التقط، بينما لا يزال الموقع على HTTP:

• زحف كامل للموقع المباشر — احفظ كل عنوان 200 URL، والأهم من ذلك، كل إعادة توجيه موجودة وهدفها. ستعيد تشغيل هذا الزحف بعد الإطلاق وتقارن بينهما؛ أي شيء كان 200 وأصبح الآن 404 هو تراجع.
• لقطة من الترتيب لكلماتك المفتاحية المتتبعة، بحيث يكون للانخفاض بعد الإطلاق خط أساس.
• تصدير من Search Console — الأداء (الاستعلامات، الصفحات، النقرات، مرات الظهور)، تقرير فهرسة الصفحات، وإحصائيات الزحف. بيانات GSC لا تنتقل من خاصية HTTP إلى خاصية HTTPS، لذا فإن هذا التصدير هو سجلك الوحيد لـ “قبل”.
• ملف الروابط الخلفية الخاص بك، حتى تعرف أي عناوين URL تحمل أكبر قدر من القيمة الخارجية وبالتالي تحتاج أكثر إلى إعادة توجيه نظيفة من خطوة واحدة.
• ملف robots.txt وأي توجيهات noindex كما هي — ستحتاج إلى التأكد من أن أياً منها لا ينتقل بصمت ليمنع موقع HTTPS.

الخطوة 2 — اختر شهادة TLS وقم بتثبيتها

إليك الحقيقة المتعلقة بـ SEO التي توفر على الناس المال: إشارة الترتيب تفحص مخطط عنوان URL، وليس الشهادة. وصفها غاري إيليس بأنها “تنظر بشكل أساسي إلى الأحرف الخمسة الأولى أمام عنوان URL، وإذا كانت HTTPS … فستحصل على دفعة بسيطة.” لذا بالنسبة لـ SEO، شهادة التحقق من النطاق (DV) المجانية — Let’s Encrypt هي الافتراضية — تحصل على نفس الإشارة تمامًا مثل شهادة OV أو EV المدفوعة. OV/EV تشتري الهوية التنظيمية، وليس الترتيب. لا تعد نفسك (أو عميلاً) بتحسين في الترتيب، أو بفائدة خاصة لنوع معين من الشهادات أو خوارزمية مفاتيح — وصف Google الخاص يسمي هذا إشارة خفيفة وبسيطة، وليس رافعة تستحق الدفع مقابلها.

ما تحتاج إلى إتقانه تقنيًا:

• النطاق. شهادة نطاق واحد تغطي اسم مضيف واحد؛ شهادة بدل (*.example.com) تغطي مستوى واحدًا من العمق — تعمل مع foo.example.com ولكن ليس foo.bar.example.com. إذا كنت تدير نطاقات فرعية عميقة، خطط لشهادة متعددة النطاقات (SAN) أو شهادات إضافية.
• قوة المفتاح. إرشادات Google هي “توليد زوج مفاتيح RSA بطول 2,048 بت” — الأقصر قابل للكسر بالقوة الغاشمة، والأطول يهدر الموارد.
• التجديد التلقائي. الحادث الأكثر شيوعًا بعد الانتقال هو شهادة منتهية الصلاحية. أتمتة التجديد (Let’s Encrypt مصممة لذلك) وراقب انتهاء الصلاحية. لاحظ الفارق الدقيق: Google تفضل عمومًا HTTPS كنسخة أساسية للصفحة، لكن هذا التفضيل مشروط، وليس تلقائيًا — شهادة غير صالحة، أو تبعيات غير آمنة، أو إعادة توجيه من HTTPS إلى HTTP، أو وسم أساسي HTTP يمكن أن يقلب اختيار Google الأساسي مرة أخرى إلى عنوان HTTP، ولا يمكن لـ HSTS تجاوز هذا التفضيل. Evidence for this claim Google generally prefers HTTPS as the canonical version of a page, but that preference is conditional: an invalid certificate, insecure dependencies, an HTTPS-to-HTTP redirect, or an HTTP canonical tag can flip Google's choice back to the HTTP URL. HSTS is a browser-only mechanism and cannot override Google's canonical selection. Scope: Describes Google's conditional HTTPS canonical preference, not a guarantee that certificate problems are search-invisible. Confidence: high · Verified: 2026-07-17 Google: Consolidate duplicate URLs لذا فإن الشهادة منتهية الصلاحية ليست حدثًا غير ضار لبحث Google — إنها في نفس الوقت حالة طوارئ لتجربة المستخدم/الأمان (تحذير متصفح بملء الشاشة يدمر ثقة المستخدم) وخطر حقيقي على تفضيل HTTPS الأساسي لديك كلما طال استمرارها. أصلحها بسرعة في كلتا الحالتين. (للتصنيف الكامل لأعطال الشهادات — منتهية الصلاحية، موقعة ذاتيًا، عدم تطابق اسم المضيف، سلسلة غير مكتملة — راجع شهادات TLS/SSL بالتفصيل.)

الخطوة 3 — تدرب على بيئة الاختبار

قم بالتبديل الكامل على نسخة اختبار/ما قبل الإنتاج أولاً. ما تتحقق منه:

• قاعدة إعادة التوجيه تعمل مع كل شكل من أشكال المسار، بما في ذلك سلاسل الاستعلام، واختلافات الشرطة المائلة في النهاية، وwww/غير www.
• لا توجد حلقة إعادة توجيه (قاعدة غير صحيحة التكوين ترتد HTTPS إلى HTTP ومرة أخرى تقفل الجميع — بما في ذلك أنت).
• الصفحات تُعرض بشكل نظيف مع عدم وجود محتوى مختلط قابل للحظر في وحدة تحكم DevTools.
• وسومك الأساسية تصدر بالفعل https:// على بيئة الاختبار.

احمِ النسخة التجريبية من الفهرسة (مصادقة أو noindex تتذكر إزالتها — noindex عابر خاص بالترحيل فقط يبقى حتى الإنتاج هو جرح كلاسيكي نصنعه بأنفسنا). إرشادات جوجل نفسها تنبه إلى هذا: لا تنسَ إزالة noindex أو كتل robots.txt التي كانت مطلوبة فقط للترحيل.

الخطوة 4 — تعيين إعادة التوجيه على نطاق واسع

بالنسبة لتبديل البروتوكول، يكون التعيين حتميًا، لذا تقوده بـقاعدة واحدة، وليس بجدول بحث ضخم:

• من جانب الخادم، واحد لواحد، ودائم (301). كل http:// URL → نفس المسار على https://. نفّذ ذلك في إعداد الخادم/الحافة (Apache أو Nginx أو CDN الخاص بك)، وليس في كود التطبيق وليس باستخدام JavaScript من جانب العميل، حتى ترى الروبوتات استجابة 301 نظيفة من الخادم.
• لا سلاسل إعادة توجيه. إذا كان لديك بالفعل عمليات إعادة توجيه HTTP (مثل http://a → http://b)، لا تدع تبديل HTTPS يحول ذلك إلى http://a → http://b → https://b. حدّث القواعد الأصلية بحيث تصل العناوين القديمة إلى وجهة HTTPS النهائية في قفزة واحدة. ستتبع جوجل حتى 10 قفزات، لكنها “تنصح بإعادة التوجيه إلى الوجهة النهائية مباشرة.” كل قفزة إضافية هي ميزانية زحف مهدرة وقليل من السرعة المفقودة.
• لا تعيد توجيه جماعي إلى الصفحة الرئيسية. يجب أن تظل العناوين غير المتطابقة تحل إلى نظيرها على HTTPS. إغراق كل شيء على / هو خطأ الترحيل الذي يفقد الترتيب فعليًا.
• تحقق من الخريطة بالزحف. أعد زحف قائمة عناوين HTTP بعد الإطلاق وتأكد أن كل عنوان يعيد 301 واحدًا إلى عنوان HTTPS الصحيح — وليس 302، وليس سلسلة، وليس 404.

الخطوة 5 — أعد توجيه كل إشارة canonical وsitemap وhreflang

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

• Canonical. يجب أن تحمل كل صفحة وسم rel="canonical" يشير إلى نفسها موجهًا إلى عنوان https:// الخاص بها — إرشادات نقل الموقع من جوجل تنص على “يجب أن يحتوي كل عنوان جديد على وسم rel=“canonical” يشير إلى نفسه <link>.” canonical لا يزال يشير إلى http:// يقاوم ترحيلك. (هذا بالضبط نوع الإشارات المتضاربة التي يحذر منها موضوع canonicalization — وائم كل الإشارات على عنوان HTTPS.)
• الروابط الداخلية. غيّرها في القوالب والمحتوى إلى https:// (أو روابط نسبية للبروتوكول/نسبية للجذر) — لا تترك آلاف الروابط الداخلية تشير إلى http:// وتعتمد على إعادة التوجيه للتنظيف. كل رابط داخلي http:// هو قفزة إعادة توجيه غير ضرورية لكل من المستخدمين والروبوتات.
• خرائط XML للموقع. أعد توليدها بعناوين HTTPS فقط، مع سرد الصفحات canonical القابلة للفهرسة، وحدّث lastmod. أرسل خريطة الموقع الجديدة في GSC بعد الإطلاق.
• Hreflang. إذا كنت تدير إعدادًا دوليًا، يجب أن يشير كل تعليق hreflang إلى نسخة HTTPS من كل بديل. hreflang نصف مُرحَّل (بعض http، بعض https) هو خطأ SEO دولي صامت يصعب تشخيصه.
• البيانات المنظمة وعناوين Open Graph. og:url، ومراجع canonical داخل JSON-LD، وأي عناوين مطلقة مكتوبة يدويًا يجب أن تكون جميعها HTTPS.

الخطوة 6 — اقتل المحتوى المختلط قبل الإطلاق، وليس بعده

المحتوى المختلط هو صفحة HTTPS تحمّل موردًا فرعيًا عبر HTTP. إنه أكثر تراجع شائع في يوم الإطلاق. المصطلحات الحالية (التقسيم القديم “نشط/سلبي” تاريخي، لكنك ستظل تراه في الوثائق والأدوات الأقدم) تقسمه حسب ما يفعله المتصفح به:

• محتوى مختلط قابل للحظر — البرامج النصية، أوراق الأنماط، الإطارات المضمنة، XMLHttpRequest/ fetch (الفئة “النشطة” القديمة). تحظرها المتصفحات تمامًا لأن البرنامج النصي المعدل يمكنه إعادة كتابة الصفحة بأكملها. هذا هو ما يكسر الموقع فعليًا بعد التبديل: ورقة أنماط محظورة أو حزمة JS يمكن أن تترك الصفحة بدون تنسيق أو غير وظيفية. أصلح هذه أولاً.
• محتوى مختلط قابل للترقية (قابل للحظر اختياريًا) — الصور، الصوت، الفيديو (الفئة “السلبية” القديمة). المتصفحات الحديثة بشكل متزايد تقوم بترقية تلقائية لهذه الطلبات إلى HTTPS بشفافية وتحظرها إذا فشلت الترقية، بدلاً من مجرد التحذير وعرضها عبر HTTP؛ تعامل مع “لا يزال يتم تحميله” كسلوك يعتمد على إصدار المتصفح، وليس كضمان. أصلحها بعد ذلك بغض النظر.
• توجد استثناءات — بعض سياقات المتصفح/التضمين (موارد محملة عبر إضافات معينة، بعض حالات <applet>/<embed> القديمة) لا تتبع أيًا من القاعدتين بشكل نظيف، وهو سبب إضافي للتحقق من السلوك في المتصفحات التي يستخدمها جمهورك فعليًا بدلاً من افتراض القاعدة العامة.

ابحث عنه عن طريق زحف موقع HTTPS (Ahrefs Site Audit، Screaming Frog)، أو مراقبة وحدة تحكم Chrome DevTools، أو جمع تقارير CSP. كشبكة استباقية انتقالية، يخبر رأس Content-Security-Policy: upgrade-insecure-requests المتصفح بأن يقوم بترقية طلبات الموارد الفرعية http:// إلى https:// بصمت قبل إجرائها — لكن رأس CSP لا يثبت أن إصدار HTTPS من كل نقطة نهاية موجود فعليًا أو يتصرف بنفس طريقة إصدار HTTP، ولا يحل محل إصلاح عناوين URL المصدر أو الاختبار في متصفحات حقيقية. توضيح واحد يوفر الارتباك: رابط ربط عادي لصفحة HTTP ليس محتوى مختلطًا — إنه مجرد تنقل.

الخطوة 7 — اجعل تغطية Search Console صحيحة

هذه هي الخطوة التي يقلل الناس من شأنها — لكنها قرار، وليست قائمة تحقق عامة. خصائص بادئة URL في Search Console تتبع http://example.com، http://www.example.com، https://example.com، و https://www.example.com كأربع خصائص منفصلة لا تشارك البيانات. أنت لست مطالبًا بالتحقق من الأربعة جميعًا:

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

في كلتا الحالتين:

• أرسل خريطة موقع HTTPS الجديدة أينما كنت تتبع الموقع (خاصية النطاق أو خاصية بادئة URL الخاصة بـ HTTPS).
• لا تستخدم أداة تغيير العنوان. Google صريحة: “If you’re moving your site from HTTP to HTTPS, you don’t need to use the Change of Address tool.” (ترجمة) «إذا كنت تنقل موقعك من HTTP إلى HTTPS، فلست بحاجة إلى استخدام أداة تغيير العنوان.» تلك الأداة مخصصة فقط للتحركات على مستوى النطاق، واستخدامها هنا خطأ حسن النية.
• احتفظ بأي خصائص HTTP قمت بالتحقق منها بالفعل — ستظهر عمليات إعادة التوجيه التي تتم معالجتها وعناوين URL القديمة التي تخرج من الفهرس، وهو إشارة مراقبة مفيدة، وليس فوضى.
• أعد النظر في ملف التنصل الخاص بك، إذا كان لديك واحد — إدخالاته تشير إلى عناوين URL الخاصة بـ HTTP، وهو يعيش لكل خاصية.

لتشخيص عناوين URL الفردية بدلاً من تتبع الموقع بأكمله، فإن تقرير HTTPS في GSC يشير إلى أسباب الشهادة، وإعادة التوجيه، والكنسي، والروبوتات، وتقييم خريطة الموقع التي تمنع عنوان URL من الانتقال إلى HTTPS. تعامل معه كأداة تشخيصية بعينة، وليس جردًا كاملاً — إنه مأخوذ بعينة ويتجاهل معلمات الاستعلام عند مطابقة عناوين URL، لذا لن يلتقط كل ما قد يلتقطه الزحف الخاص بك. راجع الغوص العميق في تقرير HTTPS الخاص بـ GSC لمعرفة كيفية قراءته.

الخطوة 8 — نوافذ المراقبة: الاستقرار مقابل الكسر

توقع “تقلبًا مؤقتًا في ترتيب الموقع أثناء النقل” — هذا أمر طبيعي وليس سببًا للذعر أو التراجع. الانضباط هو التمييز بين الانخفاض المؤقت والانخفاض الناتج عن مشكلة:

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

لا يوجد إطار زمني ثابت للتعافي — تابع هذه المؤشرات بشكل مستقل بدلاً من انتظار رقم واحد ليقول “تم”:

• سلوك TLS/المتصفح — صلاحية الشهادة وسلسلة الشهادات، ووحدة تحكم DevTools الفعلية على صفحات ممثلة (بدون أخطاء محتوى مختلط، بدون تحذيرات شهادة). هذا هو المؤشر الذي لن تخبرك به مقاييس البحث.
• إحصائيات الزحف في GSC على أي مكان تتابع فيه الموقع — تريد رؤية Googlebot يجلب عناوين HTTPS ويبقى مزيج رموز الاستجابة صحيًا (معظمها 200 + 301 على العناوين القديمة). ارتفاع في 5xx يعني أن خادمك يعاني تحت الحمل الجديد.
• تقرير فهرسة الصفحات — عناوين HTTPS تنتقل إلى “مفهرس”، وعناوين HTTP تنتقل إلى “صفحة مع إعادة توجيه”. هذا التقاطع هو بالضبط ما تريد رؤيته.
• فحص URL على عدد قليل من الصفحات الرئيسية — تأكد من أن canonical المبلغ عنه هو عنوان HTTPS وأن الصفحة تُعرض بدون محتوى مختلط.
• سجلات الخادم — الحقيقة المطلقة حول العناوين التي يزورها الروبوتات فعليًا والرموز التي حصلوا عليها. راقب الروبوتات التي لا تزال تصل إلى عناوين HTTP (أمر مقبول لفترة قصيرة) أو التي تصطدم بسلاسل/حلقات (غير مقبول).
• التحليلات ونتائج الأعمال — قد يظهر جزء من حركة المرور “المباشرة” لأن بيانات الإحالة HTTPS→HTTP تُجرد، لذا تأكد من أن روابطك الصادرة تذهب إلى وجهات HTTPS؛ وتابع التحويلات/الإيرادات بشكل مستقل — تعافي مقياس الترتيب لا يضمن تعافي مقاييس الأعمال أيضًا.

راقب بنشاط لمدة 2–4 أسابيع كقاعدة عامة، ثم أبقِ عينًا أخف على الأمر حتى يكتمل انتقال الفهرسة بالكامل — المواقع الأكبر أو الأبطأ في الزحف قد تحتاج وقتًا أطول، ولا يوجد تاريخ نهاية مضمون.

الخطوة 9 — أبقِ عمليات إعادة التوجيه، وأضف HSTS بشكل متعمد

• أبقِ 301s لفترة طويلة. إرشادات Google هي “لأطول فترة ممكنة، عمومًا سنة واحدة على الأقل” — هذا حد أدنى توصي به Google، وليس تاريخ انتهاء يصبح من الآمن بعده إزالتها. عمليًا، أبقِها طوال عمر الموقع — الروابط الخارجية والإشارات المرجعية على عناوين http:// القديمة لا تختفي تمامًا أبدًا.
• HSTS طبقة ثانية، وليس بديلاً. يخبر رأس Strict-Transport-Security المتصفحات باستخدام HTTPS دائمًا لنطاقك، مما يسد “مشكلة الطلب الأول” (أول طلب من زائر جديد يخرج عبر HTTP قبل إطلاق 301 — النافذة التي يريدها المهاجم الذي يجرد SSL). لكن عندما يحترم المتصفح HSTS، يقوم بإعادة توجيه داخلية 307 خاصة بالمتصفح لا يراها الزاحفون أبدًا — محركات البحث لا تزال تحتاج إلى 301 من جانب الخادم. تحتاج كليهما.
• تعامل مع HSTS preload كأمر بطيء ومحفوف بالمخاطر للتراجع — وليس بابًا أحادي الاتجاه حرفيًا. إرسال النطاق إلى قائمة preload المدمجة في المتصفح (التي تتطلب max-age لا تقل عن سنة، وincludeSubDomains — مما يعني أن السياسة تنطبق على كل نطاق فرعي، وليس فقط النطاق الذي أرسلته، لذا أي نطاق فرعي ليس جاهزًا تمامًا لـ HTTPS سيتعطل تحتها — وpreload) يسد الفجوة حتى للزوار الجدد. الإزالة ممكنة فعليًا عبر hstspreload.org، لكنها بطيئة (يجب أن ينتشر التغيير عبر دورات إصدار المتصفح) وكل متصفح موجود بالفعل على القائمة القديمة يستمر في فرض HTTPS فقط حتى يتم تحديثه — محفوف بالمخاطر تشغيليًا، وليس غير قابل للعكس حرفيًا. تحذير Google صريح: “لا تقم بتمكين HSTS حتى تتأكد من أن تشغيل موقعك قوي بما يكفي لتجنب نشر HTTPS مع أخطاء التحقق من الشهادة.” (ترجمة) «لا تقم بتمكين HSTS حتى تتأكد من أن تشغيل موقعك قوي بما يكفي لتجنب نشر HTTPS مع أخطاء التحقق من الشهادة.»

الخطوة 10 — ضع خطة تراجع (واعرف حدودها)

حتى الترحيل منخفض المخاطر يستحق مخرجًا — لكن الحركة الافتراضية عند حدوث خلل هي إصلاح HTTPS، وليس العودة إلى HTTP. “التراجع” هو شبكة أمان محدودة، وليس عكسًا مضمونًا: التوجيهات 301 المخزنة مؤقتًا في المتصفحات وشبكات CDN، وملفات تعريف الارتباط الموسومة بـ Secure، وعمال الخدمة المسجلين تحت نطاق HTTPS، وسياسة HSTS/التحميل المسبق يمكن أن تجعل تقديم HTTP مرة أخرى غير آمن أو ببساطة غير فعال لجزء من زوارك، حتى لو فعلت كل شيء بشكل صحيح عند الإطلاق.

قبل التبديل:

• اختر وقت الإطلاق لحركة مرور منخفضة — تقترح Google صراحةً أن “توقيت انتقالك ليتزامن مع حركة مرور أقل، إن أمكن.” نافذة هادئة تعني أن عددًا أقل من المستخدمين سيواجهون أي خلل في يوم الإطلاق، ولديك مساحة للتفاعل.
• أبقِ HTTP يعمل تحت التوجيه. لا تقم بإزالة مستمع HTTP؛ أبقِه نشطًا حتى يكون للتوجيهات 301 ما تنطلق منه، وحتى يكون عكس قاعدة التوجيه متاحًا كخيار إذا كان موقع HTTPS معطلاً بشدة.
• لا تفعّل HSTS في اليوم الأول. HSTS (وخاصة التحميل المسبق) يجعل التراجع إلى HTTP أقل جدوى بكثير — بمجرد أن يخزن المتصفح السياسة، لن يتحدث مع HTTP إلى نطاقك بغض النظر عن ما يفعله خادمك. أضف HSTS فقط بعد أن يثبت موقع HTTPS استقراره لفترة من الوقت.
• حدد معايير الإلغاء مسبقًا — على سبيل المثال، 5xx على مستوى الموقع، أو حلقة توجيه، أو حظر واسع للمحتوى المختلط. عندما تصل إليها، عالج المشكلة بهذا الترتيب: (1) هل يمكنك إصلاح خلل HTTPS مباشرة (شهادة خاطئة، مورد مفقود، canonical مكسور)؟ عادةً نعم، وهذا أسرع وأكثر أمانًا من التراجع. (2) فقط إذا كان HTTPS نفسه غير قابل للاستخدام، اعكس قاعدة التوجيه كإجراء مؤقت — وتوقع أن يكون غير مكتمل: التوجيهات المخزنة مؤقتًا سابقًا، وملفات تعريف الارتباط، وعمال الخدمة لن تلغي تخزينها المؤقت بمجرد أن يغير خادمك رأيه.

شخّص بهدوء بدلاً من تصحيح الأخطاء مباشرة، وتعامل مع “العودة إلى HTTP” كخيار كسر الزجاج الذي تأمل ألا تحتاجه أبدًا — وليس كتراجع روتيني ونظيف.

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

نظرة مختصرة على النسخة المتقدمة:

• إنه ترحيل بروتوكول فقط — بشروط. نفس المضيف، والمسارات، وسلاسل الاستعلام، والمحتوى، والمنصة؛ فقط المخطط يتغير. أقل ترحيل خطر موجود إذا تحققت الشروط الخمسة جميعها، لذا تتطابق عناوين URL واحدًا لواحد ويكون منطق إعادة التوجيه عادةً قاعدة واحدة. لا توجد أداة تغيير العنوان (تلك مخصصة لنقل النطاقات). إذا كان هناك أي شيء آخر يتغير أيضًا، فتعامل معه كترحيل مكدس بدلاً من ذلك.
• قيّم أولاً: زحف كامل (احفظ كل 200 وإعادة التوجيه الحالية)، لقطة للترتيبات، تصدير GSC (البيانات لا تنتقل إلى خاصية HTTPS)، ملف الروابط الخلفية، وrobots/noindex الحالي.
• الشهادة: إشارة الترتيب مبنية على المخطط، لذا شهادة DV مجانية (Let’s Encrypt) تحصل على نفس الإشارة الخفيفة مثل أي شهادة مدفوعة؛ OV/EV تشتري الهوية، وليس الترتيبات — لا تعد بتحسين الترتيب لأي نوع شهادة أو خوارزمية مفتاح. مفتاح 2 048 بت؛ راقب نطاق wildcard (عمق تسمية واحدة)؛ أتمتة التجديد. تفضل Google عمومًا HTTPS كمعيار، لكن هذا التفضيل مشروط — شهادة سيئة، أو تبعيات غير آمنة، أو إعادة توجيه HTTPS→HTTP، أو علامة canonical HTTP يمكن أن تعيده إلى HTTP، وHSTS لا يمكنها تجاوز ذلك.
• جرّب على بيئة الاختبار — كل شكل مسار يعيد التوجيه، بدون حلقات، بدون محتوى مختلط قابل للحظر، canonicals تصدر HTTPS بالفعل؛ أزل أي noindex خاص بالترحيل قبل وصوله إلى الإنتاج.
• التحويل: أعد توجيه 301 لكل عنوان URL واحد لواحد، من جانب الخادم (301 لا تفقد PageRank)؛ بدون سلاسل (أعد التوجيه إلى وجهة HTTPS النهائية في قفزة واحدة)؛ لا تعيد التوجيه الجماعي إلى الصفحة الرئيسية؛ ثم أعد توجيه canonicals (HTTPS ذاتي المرجع)، والروابط الداخلية، وخرائط المواقع، وhreflang، وعناوين OG/JSON-LD.
• المحتوى المختلط: المصطلحات الحالية هي قابل للحظر (البرامج النصية/الأنماط/iframes/XHR — المتصفحات تحظر تمامًا، أصلحها أولاً) وقابل للترقية (الصور/الصوت/الفيديو — المتصفحات الحديثة ترقي تلقائيًا إلى HTTPS أو تحظر عند الفشل، وليس فقط تحذر)؛ الانقسام القديم النشط/السلبي تاريخي. upgrade-insecure-requests CSP هو شبكة انتقالية، وليس دليلًا على وجود نقطة نهاية HTTPS. الروابط الأساسية لصفحات HTTP ليست محتوى مختلطًا.
• Search Console قرار، وليس عددًا عالميًا. أضف خاصية نطاق واحدة (تجمع كل متغيرات المخطط/المضيف تلقائيًا) — خصائص بادئة URL (http, https, http-www, https-www) هي تقسيم اختياري، وليس شرطًا. أرسل خريطة موقع HTTPS؛ راجع ملف disavow. تقرير HTTPS في GSC هو أداة تشخيصية مأخوذة من عينة (تتجاهل معلمات الاستعلام)، وليس جردًا كاملاً.
• راقب بشكل مستقل، بدون نافذة زمنية ثابتة: سلوك TLS/المتصفح، إحصائيات الزحف، فهرسة الصفحات، فحص URL، السجلات، والتحليلات/نتائج الأعمال كل منها يروي جزءًا مختلفًا من القصة. الانخفاض الذي يتعافى على مدى أيام إلى أسابيع هو استقرار؛ الانخفاض الذي يستمر يعني أن شيئًا ما انكسر (حظر عشوائي، canonical مفقود، روابط داخلية HTTP، سلاسل).
• أبقِ إعادة التوجيه ≥ سنة واحدة كحد أدنى، وليس تاريخ انتهاء (معظم المواقع تبقيها إلى أجل غير مسمى). HSTS هو 307 خاص بالمتصفح فقط لا تراه برامج الزحف — بالإضافة إلى، وليس بدلاً من، 301. Preload بطيء ومحفوف بالمخاطر للتراجع — ممكن فعلاً عبر hstspreload.org، لكن ليس شيئًا يجب التسرع فيه.
• خطة التراجع، مع حدود: أصلح HTTPS أولاً — عادةً أسرع وأكثر أمانًا من التراجع. أطلق في وقت حركة مرور منخفضة، أبقِ HTTP يعمل، لا تفعّل HSTS في اليوم الأول، حدد معايير الإيقاف — لكن إعادة التوجيه المخزنة، وملفات تعريف الارتباط، وعمال الخدمة يمكن أن تجعل التراجع الحقيقي إلى HTTP غير مكتمل حتى ذلك الحين.

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

وثائق المصدر الأساسية لتخطيط وتنفيذ الترحيل.

Google

• نقل المواقع مع تغييرات URL — دليل الترحيل: إعادة توجيه 301 من جانب الخادم، وإعادة توجيه من خطوة واحدة، وcanonical ذاتية المرجع، “أبقِ عمليات إعادة التوجيه لمدة سنة واحدة على الأقل،” “لا توجد أداة تغيير العنوان لـ HTTP→HTTPS،” و”وقّت انتقالك ليتزامن مع انخفاض حركة المرور.”
• دمج عناوين URL المكررة — إرشادات Google الشرطية لتفضيل HTTPS في canonical: يُفضَّل HTTPS عمومًا، لكن الشهادة السيئة، أو التبعيات غير الآمنة، أو إعادة توجيه HTTPS→HTTP، أو وسم canonical عبر HTTP يمكن أن تعكس هذا التفضيل إلى HTTP.
• تفعيل HTTPS على خوادمك (web.dev) — الشهادات، مفاتيح 2048-بت، إعادة توجيه 301 إلى canonical عبر HTTPS، HSTS، وملفات تعريف الارتباط.
• لماذا يهم HTTPS (web.dev) — حالة الأمان وميزات المتصفح للانتقال.
• إصلاح المحتوى المختلط (web.dev) — المحتوى المختلط القابل للحظر مقابل القابل للترقية (اختياري الحظر) — المصطلحات الحالية لما يُسمى تاريخيًا نشط/سلبي — وupgrade-insecure-requests.
• HTTPS كإشارة ترتيب (2014) — المنشور الأصلي “إشارة خفيفة جدًا”، بالإضافة إلى ملاحظات تنفيذ Google (نوع الشهادة، عناوين URL النسبية، لا تحظر HTTPS في robots.txt).
• فهم تجربة الصفحة — حيث يقع HTTPS وتقرير HTTPS في GSC.

الشهادات والتكوين

• Let’s Encrypt — شهادات DV مجانية ومؤتمتة مع تجديد مدمج.
• اختبار خوادم SSL Labs — قيّم تكوين TLS بعد التثبيت.
• hstspreload.org — أهلية التحميل المسبق لـ HSTS وتحذيرات الإزالة.

Chrome / Chromium

• ويب آمن هنا ليبقى (2018) — Chrome 68 يعلّم جميع HTTP “غير آمن”، الموعد النهائي الذي دفع معظم المواقع إلى الترحيل.

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

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

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

• “301 and other permanent redirects don’t cause a loss in PageRank.” (ترجمة) «لا تسبب عمليات إعادة التوجيه الدائمة 301 وغيرها فقدانًا في PageRank.» — Google Search Central. الانتقال إلى الاقتباس
• “Keep the redirects for as long as possible, generally at least 1 year.” (ترجمة) «أبقِ عمليات إعادة التوجيه لأطول فترة ممكنة، عمومًا سنة واحدة على الأقل.» — Google Search Central. الانتقال إلى الاقتباس
• “Each new URL should have a self-referencing rel=“canonical” <link> tag.” (الترجمة العربية) «يجب أن يحتوي كل عنوان URL جديد على وسم <link> rel=“canonical” ذاتي المرجع.» — Google Search Central. الانتقال إلى الاقتباس

Google — تفاصيل HTTP→HTTPS

• “If you’re moving your site from HTTP to HTTPS, you don’t need to use the Change of Address tool.” (ترجمة) «إذا كنت تنقل موقعك من HTTP إلى HTTPS، فلست بحاجة إلى استخدام أداة تغيير العنوان.» — Google Search Central. الانتقال إلى الاقتباس
• “Expect temporary fluctuation in site ranking during the move.” (ترجمة) «توقع تقلبًا مؤقتًا في ترتيب الموقع أثناء النقل.» — Google Search Central. الانتقال إلى الاقتباس

Google — HSTS والشهادات (web.dev)

• “Use HTTP Strict Transport Security (HSTS) to avoid the cost of the 301 redirect.” (الترجمة العربية) «استخدم أمان النقل الصارم عبر HTTP ‏(HSTS) لتجنب كلفة إعادة التوجيه 301.» — web.dev (Google). الانتقال إلى الاقتباس
• “Don’t enable HSTS until you’re certain your site operation is robust enough to avoid ever deploying HTTPS with certificate validation errors.” (الترجمة العربية) «لا تفعّل HSTS حتى تتأكد من أن تشغيل موقعك متين بما يكفي لتجنب نشر HTTPS بأخطاء في التحقق من الشهادة.» — web.dev (Google). الانتقال إلى الاقتباس

غاري إليس — الإشارة تعتمد على المخطط

• “Basically looking at the first five characters in front of the URL, and if it’s HTTPS … it will get a minimal boost.” (الترجمة العربية) «ينظر النظام أساسًا إلى الأحرف الخمسة الأولى في بداية عنوان URL؛ وإذا كان HTTPS فسيحصل على تعزيز طفيف.» — Gary Illyes, Google, 2016 (via Search Engine Land). قراءة التغطية

أي مسار يجب أن أختار؟

“هل أغير شيئًا بخلاف المخطط؟”

• فقط http:// → https:// — نفس المضيف، والمسارات، وسلاسل الاستعلام، والمحتوى، والمنصة → دليل هذا المقال الخاص بتغيير المخطط فقط. قاعدة إعادة توجيه واحدة، بدون أداة تغيير العنوان.
• أيضًا تغيير النطاق، أو أسماء المضيفين/النطاقات الفرعية، أو بنية URL، أو المحتوى، أو نظام إدارة المحتوى/المنصة → توقف. هذه ترحيل مكدس عالي المخاطر — اتبع دليل ترحيل الموقع الكامل وأدرج HTTPS فيه.

“ما الشهادة التي أحتاجها؟”

• فقط أحتاج مخطط HTTPS + إشارة الترتيب → شهادة DV مجانية (Let’s Encrypt). نفس الإشارة الخفيفة مثل أي شهادة مدفوعة — لا تدفع أكثر متوقعًا تعزيزًا في الترتيب.
• تريد اسم منظمة مرئي / صناعة منظمة → OV/EV — لكن افهم أنها تشتري الهوية، وليس SEO.
• نطاقات فرعية متعددة → الشهادة الجامعة تغطي مستوى واحد فقط؛ النطاقات الفرعية العميقة تحتاج شهادة SAN/متعددة النطاقات.

“ظهر انخفاض في الترتيب بعد الإطلاق — هل أذعر أم أنتظر؟”

• خلال الأسبوعين الأولين ويتعافى ببطء → انتظر. هذا هو تبادل الفهرس بين HTTP وHTTPS. أمر طبيعي.
• لا يتعافى بعد عدة أسابيع → حدث خطأ ما. تحقق بالترتيب من: حظر robots.txt غير مقصود → noindex متبقٍ → canonical لا يزال على http:// → روابط داخلية لا تزال على http:// → سلاسل إعادة التوجيه → محتوى مختلط يحجب الصفحات.

“هل يجب أن أفعل HSTS الآن؟”

• إنه يوم الإطلاق / الترحيل لم يثبت استقراره بعد → لا. HSTS يجعل التراجع إلى HTTP أقل جدوى بكثير إذا احتجت إليه.
• HTTPS يعمل بشكل نظيف لفترة والتجديد مؤتمت → أضف الترويسة.
• هل تفكر في قائمة التحميل المسبق؟ → فقط عندما تكون متأكدًا أنك لن تحتاج إلى التراجع؛ الإزالة ممكنة فعليًا لكنها بطيئة ومحفوفة بالمخاطر التشغيلية، وليست بابًا أحادي الاتجاه حرفيًا.

“هل أحتاج إلى التحقق من جميع خصائص Search Console الأربعة؟”

• فقط أريد الاستمرارية، لا اهتمام بالبيانات المجزأة → لا. أضف خاصية نطاق واحدة؛ تغطي جميع متغيرات المخطط/المضيف تلقائيًا.
• تريد مقارنة حركة مرور HTTP المتأخرة مقابل موقع HTTPS الحي → احتفظ أو أضف خصائص بادئة URL الفردية لهذا الجزء — اختياري، وليس مطلوبًا.

“هل أحتاج إلى أداة تغيير العنوان؟”

• HTTP → HTTPS، نفس النطاق → لا. Google يقول ذلك صراحة.
• تغيير النطاق الفعلي → نعم — لكن هذا ترحيل مختلف.

“URL قديم ليس له نظير HTTPS واضح — إلى أين يعيد التوجيه؟”

• لتبديل البروتوكول يوجد دائمًا نظير → نفس المسار على https://، قفزة واحدة.
• الصفحة غير موجودة فعليًا → هذا قرار محتوى (404/410 أو إعادة توجيه إلى أقرب صفحة ذات صلة) — لا ترمِها كلها على الصفحة الرئيسية.

قائمة التحقق لترحيل HTTP → HTTPS

قبل (المعيار والتحضير)

• حفظ زحف كامل لموقع HTTP المباشر (كل 200 + كل إعادة توجيه موجودة + الهدف).
• أرشفة لقطة من الترتيبات، وتصدير GSC (الأداء، فهرسة الصفحات، إحصائيات الزحف)، وملف الروابط الخلفية.
• تسجيل robots.txt الحالي وتوجيهات noindex.
• الحصول على شهادة TLS (شهادة DV المجانية كافية)، مفتاح 2 048 بت، وتكوين التجديد التلقائي.
• التحقق من نطاق البدل (Wildcard) مقابل عمق نطاقك الفرعي.
• إجراء التبديل الكامل على بيئة الاختبار: كل شكل مسار يعيد التوجيه، لا حلقات، لا محتوى مختلط قابل للحظر، والكنونيكال يصدر HTTPS.
• توقيت الإطلاق لفترة حركة مرور أقل.
• التأكد من أن هذا فعليًا بروتوكول فقط: المضيف، المسارات، سلاسل الاستعلام، المحتوى، والمنصة كلها دون تغيير.

التبديل

• كل عنوان HTTP يعيد التوجيه بـ 301، من جانب الخادم وواحد لواحد، إلى نظيره HTTPS.
• لا سلاسل إعادة توجيه — العناوين القديمة تصل إلى الوجهة النهائية HTTPS في قفزة واحدة.
• لا إعادة توجيه جماعية إلى الصفحة الرئيسية للعناوين غير المتطابقة.
• كل صفحة تشير ذاتيًا إلى rel="canonical" لعنوان HTTPS الخاص بها.
• تحديث الروابط الداخلية، وخرائط XML، و hreflang إلى HTTPS (وليس تركها لإعادة التوجيه).
• تحديث og:url / JSON-LD / العناوين المطلقة المرمزة إلى HTTPS.
• إصلاح المحتوى المختلط القابل للحظر (البرامج النصية، الأنماط، الإطارات، XHR) — هذه تُحظر تمامًا.
• إصلاح المحتوى المختلط القابل للترقية (الصور، الوسائط) — لا تعتمد على الترقية التلقائية للمتصفح وحدها؛ تعيين upgrade-insecure-requests CSP كشبكة انتقالية، وليس كإصلاح.
• إزالة أي noindex أو كتلة robots.txt خاصة بالترحيل فقط.

Search Console وما بعدها

• إضافة خاصية النطاق في GSC (الافتراضي الموصى به) — أو التحقق من خصائص بادئة URL لـ HTTPS بشكل فردي إذا كنت تريد بيانات مجزأة تحديدًا.
• إرسال خريطة موقع HTTPS الجديدة؛ إبقاء خصائص HTTP القديمة موثقة للمراقبة، إذا كانت لديك.
• عدم استخدام أداة تغيير العنوان (Change of Address) إطلاقًا (لنقل النطاقات فقط).
• مراجعة ملف التنصل (إن وجد) بحثًا عن عناوين HTTP.
• إبقاء إعادة التوجيه لمدة سنة واحدة على الأقل كحد أدنى، وليس كتاريخ إزالة — ومن الأفضل طوال عمر الموقع.
• إبقاء مستمع HTTP نشطًا تحت إعادة التوجيه (شبكة أمان محدودة للتراجع، وليس تراجعًا مضمونًا).
• عدم تمكين HSTS في يوم الإطلاق؛ يُضاف فقط بعد أن يثبت HTTPS استقراره.
• مراقبة سلوك TLS/المتصفح، وإحصائيات الزحف، وفهرسة الصفحات، وفحص العناوين، والسجلات، ونتائج التحليلات/الأعمال لمدة 2–4 أسابيع (بدون تاريخ نهاية ثابت)؛ انخفاض لا يتعافى = شيء ما تعطل.

إجراء التشغيل القياسي: تنفيذ الترحيل

دليل تشغيل قابل للتكرار. عيّن مالكًا لكل مرحلة؛ لا تتخطَّ بروفة بيئة الاختبار.

T-minus (قبل أسبوع) — المعيار والبناء

1. زحف موقع HTTP المباشر؛ تصدير قائمة العناوين الكاملة مع رموز الحالة وإعادة التوجيه الموجودة.
2. تصدير GSC (الأداء، فهرسة الصفحات، إحصائيات الزحف) ولقطة من الترتيبات + الروابط الخلفية.
3. الحصول على شهادة DV وتثبيتها على بيئة الاختبار؛ تأكيد صحة السلسلة (SSL Labs).
4. بناء قاعدة 301 الواحدة من جانب الخادم (http → https، مع الحفاظ على المسار + الاستعلام).
5. تحديث القوالب بحيث تصدر الكانونيكال، والروابط الداخلية، وخرائط المواقع، و hreflang، و OG/JSON-LD بصيغة HTTPS.
6. إجراء فحص المحتوى المختلط على بيئة الاختبار؛ إصلاح كل ما هو قابل للحظر، ثم القابل للترقية.

T-zero (الإطلاق، فترة حركة مرور منخفضة) 7. نشر الشهادة إلى الإنتاج؛ تأكيد أن HTTPS يعمل بسلسلة صالحة. 8. تفعيل قاعدة 301. فحص فوري: عدد من العناوين يعيد كل منها 301 واحدًا إلى عنوان HTTPS الصحيح. 9. تأكيد أن الصفحة الرئيسية والقوالب العلوية تُعرض بدون أخطاء محتوى مختلط في وحدة التحكم. 10. إزالة أي كتلة noindex/robots.txt خاصة بالترحيل فقط.

T-plus (الساعة الأولى → اليوم الأول) 11. إعادة زحف قائمة عناوين HTTP القديمة؛ تأكيد 301s بقفزة واحدة، بدون سلاسل، بدون 404s، بدون حلقات. 12. إضافة خاصية النطاق في GSC (الافتراضي الموصى به)، أو التحقق من خصائص بادئة URL لـ HTTPS بشكل فردي فقط إذا كنت تريد بيانات مجزأة؛ إرسال خريطة موقع HTTPS. 13. مراقبة سجلات الخادم ومعدلات الأخطاء بحثًا عن ارتفاعات 5xx تحت الحمل الجديد.

T-plus (أول 2–4 أسابيع) 14. راقب إحصائيات الزحف في GSC وفهرسة الصفحات يوميًا: عناوين HTTPS → “مفهرسة”، عناوين HTTP → “صفحة مع إعادة توجيه”. 15. تحقق من فحص URL على الصفحات الرئيسية: الكنسي المبلغ عنه هو HTTPS، ويعرض بشكل نظيف. 16. قارن مع خط الأساس الخاص بك؛ ميّز بين الانخفاض المتعافى (الاستقرار) والانخفاض العالق (المكسور) وأصلح الأخير. 17. راجع ملف التنصل بحثًا عن عناوين HTTP.

T-plus (مستقر → مستمر) 18. بمجرد إثبات استقرار HTTPS وأتمتة التجديد، أضف ترويسة HSTS. 19. فكر في التحميل المسبق فقط إذا كنت واثقًا من أنك لن تحتاج إلى التراجع — الإزالة ممكنة لكنها بطيئة ومحفوفة بالمخاطر التشغيلية. 20. أبقِ إعادة التوجيه 301 ومستمع HTTP لمدة عام على الأقل (حد أدنى، وليس تاريخ إزالة) — ويفضل أن يكون ذلك بشكل دائم. إذا حدث أي حادث، أصلح HTTPS قبل التفكير في التراجع إلى HTTP؛ يمكن أن تجعل التخزين المؤقت وملفات تعريف الارتباط وعمال الخدمة هذا التراجع غير مكتمل.

أدلة التشغيل حسب الحالة

موقع صغير (بضع مئات من عناوين URL) على استضافة مشتركة احصل على شهادة Let’s Encrypt مجانية (معظم المضيفين يوفرونها بنقرة واحدة)، أضف قاعدة 301 الواحدة، حدّث الروابط الداخلية وخريطة الموقع، نفّذ فحصًا واحدًا للمحتوى المختلط في DevTools، تحقق من خاصية نطاق HTTPS في GSC. يمكنك إنجاز كل ذلك في فترة ما بعد الظهر. الخطر الرئيسي هو أصل http:// مُرمّز بنص ثابت منسي — ابحث عنه.

موقع كبير (أكثر من مئة ألف عنوان URL) خلف CDN ضع 301 عند الحافة (CDN/وكيل عكسي) بحيث تكون قاعدة واحدة على نطاق واسع، وليس منطقًا لكل تطبيق. قم بقياس الأداء بدقة أولاً — الزحف “قبل” وتصدير GSC هما شبكة الأمان الوحيدة لديك. توقع أن يستغرق انتقال الفهرس وقتًا أطول من الموقع الصغير؛ راقب إحصائيات الزحف بحثًا عن 5xx تحت الحمل وراقب سلاسل إعادة التوجيه حيث تتراكم إعادة توجيه HTTP القديمة الآن. أعد الزحف على دفعات للتأكد من أن 301 بقفزة واحدة.

موقع به طبقة إعادة توجيه موجودة (عمليات ترحيل سابقة، عناوين URL زخرفية) الفخ هو التكديس: http://old → http://new → https://new. أعد كتابة قواعد المصدر بحيث يصل كل عنوان URL قديم إلى الوجهة النهائية HTTPS في قفزة واحدة. افحص السلاسل صراحةً بعد الإطلاق — هذا هو المكان الذي تتسرب فيه القيمة.

موقع دولي مع hreflang يجب أن تشير كل تعليقة hreflang وروابط العودة الخاصة بها إلى بدائل HTTPS. مجموعة hreflang نصف المهاجرة (بعضها http، وبعضها https) تكسر الاستهداف بصمت. أعد إنشاء جميع التعليقات من مصدر حقيقة واحد على HTTPS.

لقد قمت بالفعل بالتبديل وانخفضت الترتيبات ولم تتعافَ اعمل على التشخيص بالترتيب: (1) هل هناك أي شيء محظور في robots.txt أو يحمل noindex متبقيًا؟ (2) هل تشير العناوين الكنسية إلى https://؟ (3) هل الروابط الداخلية على HTTP؟ (4) هل هناك سلاسل أو حلقات إعادة توجيه؟ (5) هل المحتوى المختلط القابل للحظر يكسر الصفحات، أم شهادة سيئة تعيد تفضيل Google الكنسي إلى HTTP؟ معظم قصص “HTTPS قتل ترتيباتي” هي واحدة من هذه الخمس — وليس تبديل البروتوكول نفسه. أصلح مشكلة HTTPS الأساسية مباشرةً؛ لا تقفز إلى التراجع إلى HTTP كخطوة أولى.

ما لا يجب فعله

• إعادة توجيه كل شيء إلى الصفحة الرئيسية. الخطأ الأكثر تدميراً في الترحيل. يجب أن يصل كل عنوان URL قديم إلى نظيره الخاص بـ HTTPS. يحذر Google صراحةً من إعادة توجيه العديد من عناوين URL القديمة إلى وجهة واحدة غير ذات صلة مثل الصفحة الرئيسية.
• استخدام 302 بدلاً من 301. 302 تعني “مؤقت” وتشير إلى أن النقل ليس دائماً. استخدم 301 حتى تنقل المحركات بالكامل عنوان URL وحصته.
• بناء سلاسل إعادة التوجيه. http://a → http://b → https://b يهدر ميزانية الزحف والسرعة. أعد التوجيه إلى وجهة HTTPS النهائية مباشرة.
• ترك الروابط الداخلية على http://. الاعتماد على 301 لـ “تنظيف” الروابط الداخلية يعني أن كل نقرة داخلية وكل زحف يمر عبر إعادة توجيه. أصلح الروابط.
• الكنونيكالات لا تزال تشير إلى http://. كنونيكال ذاتي يشير إلى المخطط القديم يتعارض مع الترحيل ويسبب ارتباكاً في اختيار الكنونيكال.
• تجاهل المحتوى المختلط القابل للحظر حتى بعد الإطلاق. يمكن أن يؤدي ملف CSS أو حزمة JS محظورة إلى ترك الصفحات معطلة للمستخدمين الحقيقيين في اليوم الأول. أصلح المحتوى المختلط القابل للحظر قبل التبديل.
• استخدام أداة تغيير العنوان لتبديل البروتوكول. هي مخصصة لانتقالات النطاق. يقول Google إنك لا تحتاجها هنا.
• افتراض أنك يجب أن تتحقق من جميع خصائص GSC الأربعة. لست بحاجة إلى ذلك — خاصية نطاق واحدة تجمع تلقائياً كل متغيرات المخطط/المضيف. (التحقق فقط من خاصية HTTP القديمة وعدم التحقق من أي شيء متعلق بـ HTTPS هو الخطأ الحقيقي الذي يجب تجنبه.)
• تفعيل HSTS (أو التحميل المسبق) في يوم الإطلاق. يجعل التراجع عن HTTP أقل جدوى بكثير إذا تبين أن موقع HTTPS معطل. أضفه فقط بعد أن يثبت HTTPS استقراره.
• ترك noindex خاص بالترحيل في الإنتاج. حظر noindex أو robots.txt أضفته لحماية بيئة الاختبار، ونسيت شحنه، يزيل فهرسة الموقع الجديد بهدوء.
• إيقاف مستمع HTTP فوراً. أبقِه نشطاً حتى يكون لدى 301 ما ينطلق منه وحتى يكون التراجع عن قاعدة إعادة التوجيه خياراً على الأقل.
• التعامل مع “إبقاء HTTP نشطاً” كتراجع مضمون. يمكن أن تجعل إعادة التوجيه المخزنة وملفات تعريف الارتباط وخدمات العمال خدمة HTTP مرة أخرى غير آمنة أو غير مكتملة — أصلح HTTPS أولاً، وتعامل مع التراجع كخيار أخير، وليس كتراجع روتيني.

ترحيل HTTP → HTTPS — ورقة الغش

حقائق إعادة التوجيه والتخطيط

حقائق الشهادة

الإشارات التي يجب إعادة توجيهها

المحتوى المختلط و HSTS

خصائص GSC خاصية النطاق تجمع تلقائيًا كل متغيرات المخطط/المضيف — الافتراضي الموصى به. خصائص بادئة URL (http://example.com · http://www.example.com · https://example.com · https://www.example.com) هي تقسيم اختياري، وليست متطلبًا عالميًا.

فرض الـ 301 (من جانب الخادم)

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

Apache (.htaccess)

# 301 every HTTP request to the same path on HTTPS
RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]

Nginx

# Dedicated port-80 server block that 301s to HTTPS, preserving host + path
server {
    listen 80;
    server_name example.com www.example.com;
    return 301 https://$host$request_uri;
}

التحقق من أن عنوان URL يعيد توجيه 301 نظيفًا بقفزة واحدة

تأكد من أن كل عنوان URL قديم يعيد توجيه 301 مباشرة إلى نظيره HTTPS — وليس 302، وليس سلسلة.

macOS / Linux

# Show every hop and status code for one URL
curl -sIL http://example.com/some/page \
  | grep -Ei '^(HTTP/|location):'
# Want a single 301 -> https://example.com/some/page -> 200, no extra hops

Windows (PowerShell)

# Follow redirects and print each status + Location
$r = Invoke-WebRequest -Uri "http://example.com/some/page" -MaximumRedirection 10
$r.BaseResponse.ResponseUri.AbsoluteUri   # final URL should be https://

العثور على المحتوى المختلط المتبقي في HTML

ابحث في صفحة معروضة عن الموارد الفرعية غير الآمنة (البرامج النصية/الأنماط/الصور/الإطارات).

macOS / Linux

curl -s https://example.com/ \
  | grep -Eo '(src|href)="http://[^"]+"' \
  | sort -u

وحدة تحكم Chrome DevTools — وضع علامة على الموارد الفرعية غير الآمنة في الصفحة المباشرة

الصق في وحدة التحكم على أي صفحة HTTPS لسرد كل عنصر لا يزال يشير إلى http:// (يتخطى روابط الارتساء العادية، التي ليست محتوى مختلطًا):

[...document.querySelectorAll('[src],link[href],iframe[src]')]
  .map(el => el.src || el.href)
  .filter(u => u && u.startsWith('http://'))
  .forEach(u => console.warn('Insecure sub-resource:', u));

فحص قائمة عناوين URL دفعة واحدة بعد الإطلاق (قفزات 301 مفردة)

أدخل قائمة عناوين URL HTTP المحفوظة لديك وحدد أي شيء ليس 301 نظيفًا بقفزة واحدة.

macOS / Linux

# urls.txt = one http:// URL per line (from your pre-migration crawl)
while read -r u; do
  code=$(curl -s -o /dev/null -w '%{http_code}' -I "$u")
  loc=$(curl -sI "$u" | awk -F': ' 'tolower($1)=="location"{print $2}' | tr -d '\r')
  echo "$code  $u  ->  $loc"
done < urls.txt

للفحص الشامل للموقع، يكون برنامج الزحف (Ahrefs Site Audit، Screaming Frog) أسرع من البرمجة النصية عنوان URL تلو الآخر — لكن هذه المقتطفات مفيدة للفحوصات السريعة وCI.

تدقيق خريطة الترحيل قبل الإطلاق

Act as a technical SEO reviewing an HTTP-to-HTTPS migration. I will provide a crawl
of live HTTP URLs, the current redirect export, the proposed HTTPS URL list, and a
staging crawl.

For every old URL, determine whether it maps one-to-one to the same host, path, and
query on HTTPS. Flag redirect chains, loops, 302s, homepage dumps, missing targets,
HTTP canonicals, HTTP internal links, HTTP sitemap or hreflang entries, blockable
mixed content, and staging noindex/robots blocks.

Return a table with old URL, observed status, first target, final target, expected
target, issue, severity, owner, and retest. Separate launch blockers from normal
post-launch index settling. Do not recommend the Change of Address tool for this
protocol-only move.

تشخيص الانخفاض بعد الإطلاق

Compare the pre-launch crawl and Search Console exports with the post-launch crawl,
logs, Page Indexing, Crawl Stats, and URL Inspection samples. Test for blocked
crawling, surviving noindex, HTTP canonicals or internal links, redirect chains or
loops, 5xx responses, and mixed-content rendering failures. Explain which evidence
shows normal HTTP-to-HTTPS canonical crossover and which evidence shows a broken
migration. Give the smallest reversible fix and a validation query for each finding.

إطار عمل للترحيل الخاص بالبروتوكول فقط

عامل HTTP→HTTPS كأربعة أنظمة مترابطة بدلًا من تثبيت شهادة:

1. النقل: يقدم HTTPS شهادة صالحة وسلسلة كاملة على كل اسم مضيف مطلوب.
2. التوجيه: يعيد كل عنوان HTTP URL توجيهًا دائمًا واحدًا من جانب الخادم إلى نظيره HTTPS الدقيق. الـ 301 هو الجسر الذي يحافظ على معنى URL؛ يقول Google أن التوجيهات الدائمة لا تفقد PageRank.
3. الإشارات: الكنسية، الروابط الداخلية، خرائط المواقع، hreflang، ومراجع URL المنظمة تتفق جميعها على HTTPS بدلاً من جعل الزاحفين يكتشفون النقل عبر التوجيهات.
4. الملاحظة: خط أساس محفوظ، زحف بعد الإطلاق، السجلات، وSearch Console تميز بين تقاطع فهرس متوقع وفشل تقني.

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

أدوات التحقق من الهجرة

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

صدّر النتائج قبل وبعد الإطلاق. تكون نتيجة الأداة أكثر فائدة عندما يمكن مقارنتها بتعيين URL المعتمد بدلاً من الحكم عليها بمعزل.

اختبارات إصدار الهجرة

الاختبار 1: بروفة المرحلة التجريبية

• الغرض: إثبات أن المحتوى والإشارات جاهزة لـ HTTPS قبل أن تؤثر التوجيهات على المستخدمين أو الزاحفين.
• الطريقة: زحف المسارات والقوالب التمثيلية على المرحلة التجريبية؛ فحص الكنسية، الروابط الداخلية، hreflang، خرائط المواقع، توجيهات robots، وعناوين URL للموارد المعروضة.
• النتيجة المتوقعة: تعرض الصفحات بشكل مكافئ، وتصدر إشارات HTTPS، ولا تحتوي على محتوى مختلط قابل للحظر، ولا تحمل أي حظر زحف أو فهرس خاص بالهجرة.
• مشغل الفشل: إشارات HTTP، موارد محظورة، أخطاء شهادة، أو بقاء قيد noindex/robots.
• الإجراء التالي: تأجيل الإطلاق وتصحيح القالب أو التكوين المصدر.

الاختبار 2: إعادة تشغيل التوجيه واحد لواحد

• الغرض: تأكيد أن التوجيه في الإنتاج يحافظ على وجهة كل عنوان URL قديم.
• الطريقة: إعادة تشغيل زحف عناوين HTTP URL المحفوظة عبر مدقق الحالة بالجملة و مقارنة الوجهات الأولى والنهائية مع التعيين المعتمد.
• النتيجة المتوقعة: يعيد كل عنوان URL قديم توجيهًا دائمًا واحدًا إلى نظيره HTTPS الدقيق، الذي تكون استجابته النهائية سليمة.
• مشغل الفشل: سلسلة، حلقة، 302، إغراق الصفحة الرئيسية، مسار/استعلام تغير، 4xx، أو وجهة 5xx.
• الإجراء التالي: تصحيح قاعدة التوجيه المصدر؛ إبقاء مستمع HTTP متاحًا للتراجع حتى يمر إعادة التشغيل.

الاختبار 3: فحص إشارات البحث بعد الإطلاق

• الغرض: التحقق من أن الزاحفين يتلقون قصة هجرة متسقة.
• الطريقة: فحص عناوين HTTPS الرئيسية ومراقبة السجلات، إحصائيات الزحف، وفهرسة الصفحات مقابل خط الأساس المحفوظ.
• النتيجة المتوقعة: يتم زحف عناوين HTTPS واختيارها ككنسية بينما تظهر عناوين HTTP بشكل متزايد كمعاد توجيهها؛ تبقى أخطاء الاستجابة ضمن خط الأساس المحدد للموقع.
• مشغل الفشل: كنسية HTTP مستمرة، زحف محظور على نطاق واسع، حلقات توجيه، أو زيادة مادية في 5xx.
• الإجراء التالي: تطبيق الإصلاح القابل للعكس المحدد مسبقًا؛ لا تقم بتمكين HSTS حتى يصبح إصدار HTTPS مستقرًا.

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

تحدثي

• السلامة خير من الندم مع HTTPS — مؤتمر SMX East لعام 2016 (SlideShare) — غوصي العميق في TLS، وأخطاء تنفيذ HTTPS الشائعة، ومزالق الترحيل: أخطاء 302 بدلاً من 301، وعدم وجود canonical لـ HTTPS، وأخطاء تكوين TLS SNI التي قد تؤدي إلى إلغاء فهرسة موقعك من Bing/Baidu، وفقدان بيانات الإحالة (“الحركة المظلمة”) على روابط HTTPS→HTTP. (ينطبق إخلاء المسؤولية الدائم: هذا فهمي لهذه الأنظمة، وإحصائيات التبني فيه من عام 2016.)

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

• دليل المبتدئين إلى تحسين محركات البحث التقني — حيث تندرج عمليات الترحيل وHTTPS في الصورة الأكبر.

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

• دليل Google نقل المواقع مع تغيير عناوين URL — دليل الترحيل الأساسي (301 من جانب الخادم، وإعادة توجيه من خطوة واحدة، وإبقاء عمليات إعادة التوجيه ≥ سنة واحدة، ولا توجد أداة Change of Address لـ HTTP→HTTPS).
• مستندات Google تفعيل HTTPS على خوادمك وإصلاح المحتوى المختلط — أكثر وثائق التنفيذ تركيزًا وفائدة.
• Let’s Encrypt — شهادات DV مجانية ومؤتمتة مع تجديد مدمج؛ كل ما تحتاجه لإشارة الترتيب.
• SSL Labs Server Test — قيّم تكوين TLS الخاص بك بمجرد تثبيت الشهادة.
• hstspreload.org — تحقق من الأهلية (واقرأ تحذيرات الإزالة) قبل الالتزام بالتحميل المسبق.
• HSTS — What It Is and How to Use It (Kinsta) — دليل HSTS عملي يغطي مخاطر القفل في التحميل المسبق.
• HTTPS Is Easy (Troy Hunt) — سلسلة فيديو قصيرة تزيل الغموض عن إعداد TLS من الصفر.

إحصائيات تستحق الاستشهاد

• عمليات إعادة التوجيه 301 لا تفقد PageRank. بيان Google الصريح — الرقم الذي يقتل أسطورة “الانتقال إلى HTTPS يكلف حقوق الروابط” ويحدد نهج الترحيل بأكمله. المصدر
• أبقِ عمليات إعادة التوجيه لمدة سنة واحدة على الأقل. الحد الأدنى الموصى به من Google — وليس حدًا زمنيًا يصبح بعده الإزالة آمنة؛ معظم المواقع تُبقيها إلى أجل غير مسمى. المصدر
• جميع صفحات HTTP موسومة بـ “Not Secure” منذ Chrome 68 (يوليو 2018). الموعد النهائي الذي حوّل ترحيل HTTPS من خيار إلى شرط أساسي. المصدر
• حوالي 89% من المواقع تستخدم HTTPS الآن. الترحيل يتعلق بعدم كونك المتخلف، وليس بمكسب في الترتيب (W3Techs، 2026؛ تأكد من الرقم الحالي).
• يتبع Googlebot ما يصل إلى “10 hops” (الترجمة العربية) «10 قفزات» في سلسلة إعادة التوجيه، لكن Google ينصح بإعادة التوجيه إلى الوجهة النهائية مباشرة — السقف وراء قاعدة “لا سلاسل”. المصدر

اختبر نفسك: الترحيل من HTTP إلى HTTPS

خمسة أسئلة سريعة حول إجراء ترحيل HTTP→HTTPS. اختر إجابة لكل سؤال، ثم تحقق.

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