كلاهما يعمل. والذي يضرّ الموقعَ أن يُقدَّم المحتوى نفسه على العنوانين، أو أن يُحوَّل عبر قفزتين أو ثلاث قبل الوصول. فاختر واحدًا، وأرسل ما عداه إليه بتحويلةٍ واحدة، وانتهِ.

Nginx

# a small server block whose only job is the redirect
server {
    listen 80;
    listen 443 ssl;
    server_name www.example.com;
    ssl_certificate     /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;
    return 301 https://example.com$request_uri;
}
ولا بدّ أن تغطّي الشهادةُ الاسمين معًا، وإلّا فشل التحويل من https://www بتحذيرٍ قبل أن يستطيع التحويل. فأصدرها لـexample.com وwww.example.com معًا.

Apache وLiteSpeed

RewriteEngine On
RewriteCond %{HTTP_HOST} ^www\.(.+)$ [NC]
RewriteRule ^ https://%1%{REQUEST_URI} [L,R=301]

قفزةٌ واحدة لا ثلاث

ومن الحوادث الشائعة أن يحوّل http://www إلى https://www، ثمّ إلى https://example.com. وكلُّ قفزةٍ رحلةٌ كاملة. فاجعلها واحدة.

curl -sSIL https://www.example.com/page | grep -E '^HTTP|^location'

واقرأ ذلك الخَرْج: تريد ٣٠١ واحدةً لا غير ثمّ ٢٠٠. ووجودُ ٣٠١ مرّتين يعني أنّ ثمّة تحويلةً تُحذَف.

ثمّ اجعل الموقعَ موافقًا

  • إعدادُ عنوان الموقع في تطبيقك.
  • ووسمُ الأصل في كلّ صفحة.
  • وخريطةُ الموقع.
  • وكلُّ ما كُتب في المحتوى نصًّا ثابتًا.
وإن لم يكن عندك سببٌ لتفضيل أحدهما فاستعمل النطاقَ المجرَّد: فهو أقصر، وهو الذي يكتبه الناس. والحجّةُ الحقيقيّة الوحيدة لـwww أنّ النطاقَ المجرَّد لا يكون CNAME، وهذا يهمّ إن احتجتَ يومًا أن تُوجّه القمّةَ إلى خدمةٍ تشترطه.