كلاهما يعمل. والذي يضرّ الموقعَ أن يُقدَّم المحتوى نفسه على العنوانين، أو أن يُحوَّل عبر قفزتين أو ثلاث قبل الوصول. فاختر واحدًا، وأرسل ما عداه إليه بتحويلةٍ واحدة، وانتهِ.
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، وهذا يهمّ إن احتجتَ يومًا أن تُوجّه القمّةَ إلى خدمةٍ تشترطه.
