كيفية إعداد شهادة SSL على WordPress والتحويل إلى HTTPS

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

الإجابة السريعة: ثبّت شهادة SSL من خلال لوحة تحكم الاستضافة الخاصة بك، ثم افتح الإعدادات > عام في ووردبريس وغيّر كلًا من عنوان ووردبريس (URL) وعنوان الموقع (URL) إلى إصداريهما بصيغة https. أنهِ العملية بإضافة إعادة توجيه 301 بحيث تنتهي طلبات HTTP إلى HTTPS.

SSL (اختصار لـ Secure Sockets Layer، رغم أن كل شهادة تصدر اليوم تستخدم فعليًا TLS) هو ما يحوّل http:// إلى https:// ويزيل علامة “غير آمن” من شريط العنوان. إذا أردت الخلفية أولًا، اقرأ ما هي شهادة SSL. وإلا، ابدأ بالجدول أدناه.

أي طريقة تناسب إعدادك

هناك ثلاث طرق لإضافة SSL إلى ووردبريس، والطريقة الصحيحة تعتمد بشكل شبه كامل على استضافتك. حدد إعدادك، ثم انتقل إلى تلك الطريقة.

إعدادك	استخدم هذه الطريقة	الوقت التقريبي
استضافة ووردبريس المُدارة	لا شيء لتثبيته. الشهادة عادةً مفعّلة بالفعل، فانتقل مباشرة إلى تحويل ووردبريس إلى HTTPS	5 دقائق
cPanel أو استضافة مشتركة مشابهة	الطريقة 1، خدمة AutoSSL المجانية من مزود الاستضافة	10 دقائق
مزود استضافة بدون أداة SSL، أو تريد إنجاز الأمر تلقائيًا	الطريقة 2، معالج الإضافة	10 إلى 15 دقيقة
VPS، خادم مخصص، أو شهادة مدفوعة	الطريقة 3، التثبيت اليدوي	30 دقيقة بالإضافة إلى وقت التحقق
Cloudflare أمام موقعك	الطريقة 1 أو 3، ثم ضبط إعداد SSL في Cloudflare على Full (strict). راجع قسم استكشاف الأخطاء وإصلاحها	15 دقيقة

مهما كان المسار الذي تسلكه، انسخ الموقع احتياطيًا أولًا، وإذا كان لديك بيئة تجريبية (staging)، فقم بتشغيل التغيير هناك قبل أن تلمس بيئة الإنتاج.

هل تحتاج شهادة SSL لموقع ووردبريس؟

نعم، وبالنسبة لمعظم الناس السبب هو ما يمكنهم رؤيته بالفعل: Chrome وFirefox وSafari وEdge جميعها تعلّم صفحات HTTP العادية بعلامة غير آمن في شريط العنوان. تظهر هذه العلامة على كل صفحة من صفحات الموقع الذي لا يملك شهادة، بما في ذلك نموذج تسجيل الدخول.

ثلاثة أسباب عملية لإصلاح ذلك:

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

أي شهادة SSL يجب أن يستخدمها موقع ووردبريس؟

ابدأ بالخيار المجاني، لأنه بالنسبة لنسبة كبيرة من مواقع ووردبريس هو الإجابة الصحيحة فعلًا. معظم مزودي الاستضافة يصدرون شهادات Let’s Encrypt مجانية تلقائيًا، والشهادة المجانية تشفّر حركة المرور بنفس فعالية الشهادة المدفوعة تمامًا. التشفير متطابق. ما يختلف بين شهادة SSL لووردبريس وأخرى هو ما تحقّقت منه هيئة إصدار الشهادات (CA) قبل إصدارها، وما تحصل عليه عندما يحدث خطأ ما.

مستويات التحقق

النوع	ما تتحقق منه هيئة إصدار الشهادات	يصدر خلال	يناسب
التحقق من النطاق (DV)	أنك تتحكم في النطاق	دقائق	المدونات، مواقع العروض التعريفية، معظم تثبيتات ووردبريس
التحقق من المؤسسة (OV)	النطاق بالإضافة إلى مؤسستك المسجلة	1 إلى 3 أيام عمل	مواقع الأعمال، مناطق العضوية، بوابات العملاء
التحقق الموسّع (EV)	فحص قانوني وتشغيلي كامل للشركة	1 إلى 5 أيام عمل	المتاجر التي تتعامل مع المدفوعات، القطاع المالي، وأي مكان تكون فيه الهوية مهمة

إذا كان موقعك يعمل بنطاقات فرعية، متجر على store.example.com ومدونة على blog.example.com مثلًا، فإن الشهادة الشاملة (wildcard) تغطي جميعها بشهادة واحدة بدلًا من شهادة لكل نطاق فرعي. لست متأكدًا من النوع المناسب؟ معالج SSL يحدده لك من خلال بضعة أسئلة.

متى تتوقف الشهادة المجانية عن كونها كافية

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

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

الطريقة 1: احصل على شهادة SSL مجانية من مزود استضافتك

هذا هو المسار الأسرع والذي يجب تجربته أولًا. تقريبًا كل مزود استضافة يقدّم الآن شهادات Let’s Encrypt مجانية، وغالبًا مفعّلة بالفعل.

• افتح لوحة تحكم الاستضافة الخاصة بك وابحث عن SSL/TLS، أو Let’s Encrypt، أو AutoSSL. في cPanel توجد ضمن Security.
• اختر نطاقك وأصدر الشهادة. أدرج كلًا من النطاق الأساسي وإصدار www، وإلا فسيظهر تحذير بعدم تطابق الاسم لأحدهما.
• تأكّد من تفعيل التجديد التلقائي. هذه هي الخطوة التي يتجاهلها الناس.

لا توجد لوحة استضافة على الإطلاق لأنك تشغّل VPS أو خادمًا مخصصًا خاصًا بك؟ استخدم Certbot، عميل Let’s Encrypt، الذي يصدر الشهادة من سطر الأوامر ويعدّ جدول تجديد خاصًا به.

شهادات Let’s Encrypt صالحة لمدة 90 يومًا، ومن المفترض أن يتم التجديد تلقائيًا، عادةً قبل نحو 30 يومًا من انتهاء الصلاحية. عندما تتعطل هذه الأتمتة، وهذا يحدث فعلًا، غالبًا بعد نقل نطاق أو تغيير سجل DNS، يبقى الموقع بحالة جيدة لأسابيع ثم يتحول إلى “غير آمن” بدون سابق إنذار. ضع تذكيرًا في تقويمك لتاريخ التجديد المتوقع الأول وتحقق من الشهادة باستخدام أداة فحص SSL بعد مرور ذلك التاريخ. إذا تقدّم تاريخ انتهاء الصلاحية، فإن التجديد يعمل.

الطريقة 2: ثبّت SSL على ووردبريس باستخدام إضافة

الإضافة التي يلجأ إليها معظم الناس هي Really Simple Security. كانت تُسمى Really Simple SSL حتى سبتمبر 2024، عندما أعاد الإصدار 9 تسميتها بعد أن توسّعت مجموعة ميزاتها المجانية إلى ما هو أبعد من إعداد SSL. لديها أكثر من ثلاثة ملايين تثبيت نشط.

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

• ثبّت وفعّل Really Simple Security من الإضافات > إضافة إضافة جديدة.
• اتبع عملية الإعداد التي تُفتح، أو انتقل إلى عنصر Security الجديد الذي تضيفه الإضافة إلى الشريط الجانبي للوحة التحكم. الدروس الأقدم تقول Settings > SSL، وهو المكان الذي كانت فيه الإضافة قبل إعادة التسمية. إذا كانت هناك شهادة مثبّتة بالفعل على الخادم، فإن الإضافة تكتشفها.
• إذا لم تكن هناك شهادة، اختر Install SSL certificate واتبع المعالج للحصول على شهادة Let’s Encrypt مجانية.
• اختر Activate SSL. تقوم الإضافة بتحديث عناوين URL لموقعك، وإعداد إعادة التوجيه، وإعادة تحميل لوحة التحكم عبر HTTPS.

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

الطريقة 3: ثبّت شهادة SSL يدويًا

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

• أنشئ CSR. يحمل طلب توقيع الشهادة تفاصيل نطاقك ومؤسستك إلى هيئة إصدار الشهادات. استخدم مولّد CSR الخاص بنا، أو اتبع أدلة CSR الخاصة بخادمك المحدد.
• أرسل CSR إلى هيئة إصدار الشهادات وأكمل عملية التحقق. DV تنتهي خلال دقائق، أما OV وEV فتستغرقان أيامًا.
• ثبّت الملفات. ستحصل على الشهادة نفسها بالإضافة إلى شهادة أو أكثر من الشهادات الوسيطة. في cPanel، ألصقها ضمن SSL/TLS > Manage SSL sites، متبعًا دليل تثبيت cPanel. المنصات الأخرى مشمولة في أدلة تثبيت SSL.
• تحقق باستخدام أداة فحص SSL قبل التعامل مع ووردبريس.

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

تشغيل WordPress Multisite يضيف بضع خطوات، مشمولة في دليل SSL لـ Multisite.

حوّل موقع ووردبريس الخاص بك من HTTP إلى HTTPS

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

ما يقوم به ووردبريس بنفسه

منذ ووردبريس 5.7، الصادر في مارس 2021، يكتشف النواة ما إذا كانت بيئتك تدعم HTTPS ويبلّغ عن ذلك ضمن الأدوات > صحة الموقع > الحالة، في قسم حالة HTTPS. عندما يكون HTTPS متاحًا، يوفر ذلك القسم زرًا يحوّل الموقع بالكامل بنقرة واحدة.

الأهم من ذلك، بمجرد أن يصبح كل من عنوان الموقع (URL) وعنوان ووردبريس (URL) على https، فإن ووردبريس يعيد كتابة عناوين URL غير الآمنة في المحتوى الخاص بك أثناء عرض الصفحة. الصور والروابط والمحتوى المضمن (embeds) الذي حُفظ بعناوين http على نطاقك الخاص يُعرض عبر https دون أن تعدّل قاعدة البيانات على الإطلاق. هذه هي الخطوة التي تطلب منك الدروس الأقدم القيام بها يدويًا.

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

غيّر إعدادي عنوان URL

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

• عنوان ووردبريس (URL)، حيث تعيش ملفات ووردبريس.
• عنوان الموقع (URL)، العنوان الذي يكتبه الزوار.

غيّر http:// إلى https:// في كليهما، ثم احفظ. تغيير أحدهما فقط هو الطريقة الأكثر شيوعًا لحرمان نفسك من الوصول إلى لوحة التحكم. إذا حدث ذلك، يمكنك ضبط كليهما من wp-config.php عبر FTP:

define( 'WP_HOME', 'https://example.com' );
define( 'WP_SITEURL', 'https://example.com' );

أضف هذه الأسطر فوق السطر الذي يقول “That’s all, stop editing”، واستبدل example.com بنطاقك. لاحظ أنه أثناء تعريف هذه الثوابت، تصبح الحقول في الإعدادات > عام للقراءة فقط.

متى لا تزال بحاجة إلى بحث واستبدال

إعادة الكتابة التي تقوم بها النواة تغطي المحتوى المعروض. لا تصل إلى كل مكان، لذا يبقى البحث والاستبدال هو الحل لـ:

• عناوين URL مثبّتة يدويًا في ملفات القالب أو في functions.php.
• إعدادات الإضافات المخزّنة كبيانات مسلسلة (serialized)، وهذا هو سبب عدم إجراء بحث واستبدال SQL بسيط أبدًا.
• صفوف الخيارات، والحقول المخصصة، ومحتوى الودجات المكتوب بواسطة مُنشئي الصفحات.

استخدم Better Search Replace، الذي يتعامل مع البيانات المسلسلة بشكل صحيح ولديه وضع تجريبي (dry-run)، أو WP-CLI:

wp search-replace 'http://example.com' 'https://example.com' --all-tables --dry-run

اقرأ مخرجات التشغيل التجريبي، ثم كرر الأمر بدون –dry-run لتطبيقه. انسخ قاعدة البيانات احتياطيًا أولًا.

فرض HTTPS في ووردبريس باستخدام إعادة توجيه 301

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

Apache

أضف هذا في أعلى ملف .htaccess في جذر ووردبريس الخاص بك، فوق كتلة ووردبريس:

RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]

علامة R=301 هي ما يجعلها دائمة. القاعدة المكتوبة بصيغة [R,L] تصدر إعادة توجيه مؤقتة 302 بدلًا من ذلك، وهذا خطأ يستحق التحقق منه إذا نسخت إعادة توجيه من دليل أقدم.

Nginx

Nginx لا يملك ملف .htaccess ولا يفهم قواعد إعادة الكتابة المكتوبة لـ Apache. حرّر كتلة الخادم في إعدادات موقعك بدلًا من ذلك:

server {
    listen 80;
    server_name example.com www.example.com;
    return 301 https://$host$request_uri;
}

اختبر الإعداد باستخدام nginx -t، ثم أعد التحميل باستخدام systemctl reload nginx.

فرض HTTPS على لوحة التحكم فقط

لتأمين تسجيلات الدخول ومنطقة الإدارة تحديدًا، أضف هذا إلى wp-config.php:

define( 'FORCE_SSL_ADMIN', true );

يغطي هذا wp-admin وصفحة تسجيل الدخول. لا يعيد توجيه الواجهة الأمامية، لذا فهو يكمّل إعادة التوجيه على مستوى الخادم بدلًا من استبدالها.

HSTS، بعد أن يعمل كل شيء

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

Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains"

أضف هذا فقط بعد أن يكون HTTPS مستقرًا لفترة، واترك توجيه preload معطلًا في البداية. التحميل المسبق (preloading) يصعب التراجع عنه بسرعة، وإذا كان أي شيء على نطاق فرعي لا يزال غير موجود على HTTPS، فسيصبح غير قابل للوصول.

أصلح ما يخلّفه التحويل

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

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

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

ذاكرات التخزين المؤقت وشبكة CDN

امسح ذاكرة التخزين المؤقت لصفحاتك وشبكة CDN بعد التحويل. النسخة المخزّنة مؤقتًا من صفحة HTTP ستستمر في تقديم الرمز القديم وتجعل عملية ترحيل مكتملة تبدو معطّلة.

رسائل البريد الإلكتروني والقوالب المعاملاتية

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

استكشاف مشاكل SSL في ووردبريس وإصلاحها

العرض	السبب المعتاد	الحل
حلقة إعادة توجيه لا نهائية، ERR_TOO_MANY_REDIRECTS	إعداد SSL في Cloudflare مضبوط على Flexible. Cloudflare يتحدث إلى خادمك عبر HTTP، وخادمك يعيد التوجيه إلى HTTPS، وCloudflare يعيدها مرة أخرى	اضبط وضع تشفير Cloudflare SSL/TLS على Full (strict) وحافظ على شهادة صالحة على الخادم الأصلي
حُرمت من الوصول إلى wp-admin بعد التحويل	تغيّر حقل واحد فقط من حقلي عنوان URL	اضبط WP_HOME وWP_SITEURL في wp-config.php عبر FTP
القفل مفقود في بعض الصفحات فقط	محتوى مختلط في تلك الصفحات	اعثر على مورد HTTP في وحدة تحكم المتصفح، وأصلحه من المصدر
كان الموقع بحالة جيدة، وأصبح “غير آمن” بعد أسابيع	انتهت صلاحية شهادة Let’s Encrypt لأن التجديد تعطّل	أعد الإصدار، ثم تأكد من التجديد التلقائي في لوحة التحكم الخاصة بك
يعمل في المتصفح، لكنه يفشل مع تطبيق أو بوابة دفع	الشهادات الوسيطة مفقودة من السلسلة	ثبّت حزمة CA الكاملة، ثم أعد التحقق باستخدام أداة فحص SSL
تحذير عدم تطابق الاسم على www أو النطاق الأساسي	الشهادة تغطي أحدهما فقط	أعد إصدار الشهادة لتغطي كلا الاسمين؛ إعادة التوجيه وحدها لا يمكن أن تصلح هذا، فالتحذير يظهر قبل تشغيل أي إعادة توجيه

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

بعد الترحيل: قائمة تحقق تحسين محركات البحث (SEO) وما يمكن توقعه

• أضف خاصية HTTPS في Google Search Console. خاصية HTTP لا تُبلغ عن عناوين URL بصيغة HTTPS. أضف الخاصية الجديدة واحتفظ بالقديمة، أو استخدم خاصية النطاق (Domain property)، التي تغطي كليهما. إذا كنت تستخدم Bing Webmaster Tools، فحدّثه هناك أيضًا.
• أعد إرسال خريطة موقعك (XML sitemap) بعناوين URL بصيغة https.
• تحقق من علامات canonical أنها تشير إلى https. معظم إضافات SEO تُحدَّث تلقائيًا بمجرد تغيير عناوين URL للموقع، لكن تأكد من ذلك في مصدر الصفحة.
• حدّث إعدادات خاصية Google Analytics وAds، وأي خدمة من طرف ثالث تخزّن عنوان URL لموقعك.
• حدّث الروابط الداخلية حيثما كانت مطلقة. الروابط النسبية لا تحتاج شيئًا.

ما يبدو طبيعيًا بعد ذلك، لأنه يقلق من لم يقم بهذا من قبل: سيُظهر Search Console انطباعاتك مقسّمة بين خاصيتي HTTP وHTTPS لفترة بينما يعيد Google الزحف، وغالبًا ما تتحرك الترتيبات لبضعة أسابيع قبل أن تستقر. يعامل Google الانتقال من HTTP إلى HTTPS كنقل موقع مع تغييرات في عناوين URL، لذا فإن بعض التذبذب متوقّع وليس علامة على تعطّل شيء ما. طالما أن إعادة توجيهات 301 موجودة وكل صفحة تعمل بشكل صحيح، فلا يوجد شيء لتفعله سوى الانتظار.

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

الأسئلة الشائعة

تنقل منصة مختلفة إلى HTTPS، أو تريد الإجراء العام؟ راجع دليلنا حول كيفية تحويل موقع من HTTP إلى HTTPS.