หากเว็บไซต์ของคุณถูก Google ทำเครื่องหมายว่า “ไม่ปลอดภัย” และผู้เยี่ยมชมเห็นป๊อปอัปเตือนเมื่อเข้าสู่ระบบหรือทำการชำระเงิน 63% ของผู้ใช้งานจะปิดหน้าต่างเว็บไซต์ทันที — ซึ่งหมายถึงการสูญเสียการเข้าชมและความน่าเชื่อถือของแบรนด์!
บทความนี้จะนำเสนอ วิธีการแก้ไขที่สามารถนำไปใช้ได้ทันที โดยไม่จำเป็นต้องมีความรู้ด้านการพัฒนา และสามารถกู้คืนเว็บไซต์ให้กลับสู่สถานะ “ปลอดภัย” ภายใน 2 ชั่วโมง!
ทำไมเว็บไซต์ของคุณถึงถูกทำเครื่องหมายว่า ‘ไม่ปลอดภัย’
Google ได้บังคับใช้การติดตั้งใบรับรอง SSL สำหรับทุกหน้าที่มีการป้อนข้อมูลจากผู้ใช้ (เช่น การเข้าสู่ระบบ การชำระเงิน หรือแบบฟอร์ม) ตั้งแต่ปี 2018 หากไม่มีใบรับรอง SSL เว็บไซต์จะถูกทำเครื่องหมายว่า “ไม่ปลอดภัย” ทันที
สิ่งที่ซับซ้อนมากขึ้นคือ แม้ว่าคุณจะติดตั้งใบรับรอง SSL แล้ว แต่หาก ใบรับรองหมดอายุ (เช่น ใบรับรองฟรีต้องอัปเดตทุก 3 เดือน), โดเมนไม่ตรงกัน (โดเมน www และ non-www ไม่ตรงกัน), หรือใช้ HTTP ลิงก์ในหน้าเว็บ (เช่น การเรียกโค้ดโฆษณาภายนอก) ก็สามารถทำให้ HTTPS ไม่ทำงานได้
HTTP เปรียบเสมือนการส่งข้อมูลแบบไม่เข้ารหัส
เว็บไซต์ร้านค้าปลีกออนไลน์แห่งหนึ่งไม่ใช้ HTTPS ทำให้ข้อมูลการสมัครสมาชิกของผู้ใช้งานถูกแฮ็กเกอร์ขโมยไป ทีมงานเทคนิควิเคราะห์พบว่า ผู้โจมตีใช้ Wi-Fi สาธารณะและใช้เครื่องมือ Wireshark ในการรวบรวมรหัสผ่านที่เป็นข้อความธรรมดามากกว่า 200 ตัวภายในเวลาเพียง 5 นาที
ปัญหาหลัก:
- HTTP ส่งข้อมูลทั้งหมด (รหัสผ่าน ข้อมูลการชำระเงิน ฯลฯ) เป็นข้อความธรรมดาโดยไม่มีการเข้ารหัส
- หน้าเว็บที่ไม่เข้ารหัสสามารถถูกดัดแปลงได้ง่ายกว่าหน้า HTTPS ถึง 3.6 เท่า (อ้างอิงจากรายงานความปลอดภัย Sucuri 2024)
- Google จะลดอันดับการค้นหาของหน้า HTTP ลง 15%-20% (ข้อมูลจากการทดลองของ SEMrush)
รายละเอียดที่สำคัญของใบรับรอง SSL
ในช่วงเทศกาลขายออนไลน์ของปี 2023 เว็บไซต์ขายเสื้อผ้าแห่งหนึ่งประสบปัญหาการหมดอายุของใบรับรอง SSL ทำให้หน้าเพจการชำระเงินถูกบล็อกโดยเบราว์เซอร์ ส่งผลให้สูญเสียคำสั่งซื้อไป 370,000 หยวน.
- ใบรับรองหมดอายุ: ใบรับรองฟรี (เช่น Let’s Encrypt) ต้องอัปเดตทุก 90 วัน และจะหมดอายุทันทีหากไม่อัปเดต
- โดเมนไม่ตรงกัน: ใบรับรองใช้ได้กับ
domain.comเท่านั้น ถ้าผู้ใช้เข้าถึงwww.domain.comจะเกิดคำเตือน - ไม่มีใบรับรองกลาง: โดยเฉพาะในอุปกรณ์ Android — ทำให้เกิดข้อผิดพลาด “ใบรับรองไม่สมบูรณ์”
สถานการณ์ในอุตสาหกรรม: จากเว็บไซต์ที่ใช้ HTTPS 43% ยังมีข้อผิดพลาดในการตั้งค่าใบรับรอง (อ้างอิงจาก SSL Labs 2024)
เนื้อหาผสม: “หยดน้ำเดียวสามารถทำลายทุกอย่างได้”
ผู้ดูแลระบบ WordPress รายหนึ่งกล่าวว่า “แม้จะติดตั้งใบรับรอง SSL แล้ว แต่ทำไมยังแสดงว่าไม่ปลอดภัยในแดชบอร์ด!” สุดท้ายพบว่าปัญหาคือ ภาพที่ลิงก์ด้วย HTTP ในธีม ทำให้หน้าเว็บทั้งหมดมีปัญหา
กรณีที่เกิดขึ้นบ่อย:
- ลิงก์ภาพในโพสต์เก่าที่ใช้ HTTP (เช่น
http://image.com/1.jpg) - ปลั๊กอินภายนอกเรียกใช้ API ที่ไม่ใช้ HTTPS (เช่น ป๊อปอัพฝ่ายบริการลูกค้า, โค้ดโฆษณา)
- ลิงก์ HTTP ที่ถูกฮาร์ดโค้ดในฐานข้อมูล
เครื่องมือที่ใช้ตรวจสอบ:
- เปิด Chrome แล้วกด F12 → ไปที่แท็บ Console เพื่อตรวจสอบไฟล์ที่มีข้อผิดพลาด
- ใช้ SSL Checker เพื่อตรวจสอบความสมบูรณ์ของใบรับรอง
กับดักที่ซ่อนอยู่: การดักจับเครือข่ายจากผู้ให้บริการในบางพื้นที่
บางพื้นที่ผู้ให้บริการเครือข่ายดักจับ HTTP และแทรกโฆษณาหรือการเปลี่ยนเส้นทาง เช่น ผู้ใช้จากมณฑลเสฉวนรายหนึ่งรายงานว่า “เว็บไซต์ของบริษัทที่อยู่ในพื้นที่แสดงโฆษณาการพนัน” — ซึ่งเกิดจากการดักจับของ ISP ในพื้นที่
ปัญหานี้สามารถกระตุ้นการแจ้งเตือนความปลอดภัยจากเบราว์เซอร์และผู้ใช้มักเข้าใจผิดว่าเป็นปัญหาของเว็บไซต์ ซึ่งทำให้มีการแจ้งร้องเรียนเพิ่มขึ้นถึง 280% (ข้อมูลจากกรณีศึกษา ZhanZhangZhiJia)
วิธีสมัครใบรับรอง SSL ฟรีที่สามารถทำได้อย่างรวดเร็ว (3 วิธี)
“การติดตั้ง SSL ซับซ้อนและแพงใช่ไหม?” — นี่คือความเข้าใจผิดที่ใหญ่ที่สุดที่ทำให้ผู้ประกอบการเว็บไซต์ขนาดกลางและเล็ก 90% ปล่อยให้การแจ้งเตือน “ไม่ปลอดภัย” อยู่โดยไม่ดำเนินการ
จริง ๆ แล้ว มากกว่า 430 ล้านเว็บไซต์ทั่วโลก ใช้ SSL ฟรีแล้ว (ข้อมูลจาก BuiltWith) — รวมทั้งแพลตฟอร์มขนาดใหญ่ เช่น Amazon และ WordPress
ใบรับรองฟรีมีความปลอดภัยเทียบเท่ากับใบรับรองแบบชำระเงิน ความแตกต่างคือวิธีการตรวจสอบเท่านั้น
1. ติดตั้งด้วยคลิกเดียวจากแผงควบคุมโฮสติ้ง (แนะนำสำหรับมือใหม่)
ใช้ได้กับ: ผู้ใช้โฮสติ้งแบบแชร์/เซิร์ฟเวอร์คลาวด์ (เช่น Alibaba Cloud, Tencent Cloud, SiteGround)
ขั้นตอนการดำเนินการ：
- เข้าสู่ระบบหน้าแดชบอร์ดของผู้ให้บริการโฮสติ้งและค้นหาหมวดหมู่ “SSL/TLS” หรือ “ความปลอดภัย”
- เลือก “ใบรับรองฟรี” และเลือกโดเมนที่ต้องการเข้ารหัส (สามารถเลือกหลายโดเมนได้)
- คลิก “ติดตั้ง” และรอประมาณ 3-5 นาทีเพื่อให้ระบบทำการติดตั้งอัตโนมัติ
อัตราความสำเร็จ：98%（ผู้ให้บริการโฮสติ้งในจีนส่วนใหญ่มีการตั้งค่าไว้ล่วงหน้า）
ข้อดี：ไม่จำเป็นต้องมีความรู้ทางเทคนิค, อัปเดตอัตโนมัติ, อัตราความล้มเหลวน้อยมาก
ข้อควรระวัง：
- บางผู้ให้บริการโฮสติ้งอาจจำกัดจำนวนใบรับรองฟรี (เช่น xinnet ให้บริการเพียงใบเดียว)
- ตรวจสอบให้แน่ใจว่าโดเมนของคุณเชื่อมต่อกับ IP ของเซิร์ฟเวอร์ในปัจจุบัน
2. Let’s Encrypt + Certbot (แนะนำโดยนักพัฒนา)
สถานการณ์การใช้งาน：เซิร์ฟเวอร์ส่วนตัว (Nginx/Apache เป็นต้น), การจัดการหลายโดเมน
กรณีตัวอย่าง：บล็อกเว็บไซต์ที่มีผู้เข้าชมมากกว่า 100,000 คนต่อวัน สามารถเข้ารหัสโดเมนย่อย 100 ตัวได้ใน 3 นาทีผ่านคำสั่ง CLI
วิธีการติดตั้ง：
# ติดตั้ง Certbot (ตัวอย่างสำหรับ Ubuntu + Nginx)
sudo apt-get update
sudo apt-get install certbot python3-certbot-nginx
# ขอติดตั้งใบรับรองและตั้งค่าอัตโนมัติ (เปลี่ยน yourdomain.com เป็นโดเมนจริง)
sudo certbot --nginx -d yourdomain.com -d www.yourdomain.com
# ตั้งค่าการอัปเดตอัตโนมัติ (ใบรับรองมีอายุ 90 วัน)
sudo certbot renew --dry-runอัตราความสำเร็จ：92%（ขึ้นอยู่กับการตั้งค่าของเซิร์ฟเวอร์）
ข้อผิดพลาดที่พบบ่อยและวิธีการแก้ไข：
Failed to connect to host for DVSNI challenge→ ตรวจสอบว่าเปิดพอร์ต 80/443 ในไฟร์วอลล์แล้วหรือยังThe server experienced an internal error→ อาจจะยังไม่ได้สะท้อนการตั้งค่า DNS รอซักครู่แล้วลองใหม่
3. ใช้ฟังก์ชัน HTTPS ของผู้ให้บริการ CDN (เร่งความเร็ว + การเข้ารหัส)
แพลตฟอร์มที่รองรับ：Cloudflare, Baidu Cloud Accelerate, Tencent Cloud CDN
วิธีการตั้งค่า (ตัวอย่างสำหรับ Cloudflare)：
- ลงทะเบียนบัญชีและเพิ่มโดเมนของเว็บไซต์
- ในหน้าการตั้งค่า “SSL/TLS” ให้เลือกโหมด “Flexible” (บังคับใช้ HTTPS สำหรับทั้งเว็บไซต์)
- เปิดใช้งาน “Always Use HTTPS” และ “Automatic HTTPS Rewrites”
เวลาที่ใช้ในการนำไปใช้：ใช้เวลาไม่นาน (การตั้งค่าจะเผยแพร่ไปยังโหนดทั่วโลกทันที)
ข้อดีหลัก：
- ไม่จำเป็นต้องติดตั้งใบรับรองบนเซิร์ฟเวอร์ต้นทาง, โหนดของ CDN จะเข้ารหัสอัตโนมัติ
- สามารถใช้ได้กับเซิร์ฟเวอร์ HTTP เก่า ๆ และแก้ไขปัญหาคอนเทนต์ผสม
- รองรับใบรับรอง Wildcard ในแผนฟรี (*.domain.com)
ข้อจำกัดและวิธีการแก้ไข
| ข้อจำกัด | ขอบเขตที่ได้รับผลกระทบ | วิธีการแก้ไข |
|---|---|---|
| ระยะเวลาใช้งานสั้น | ใบรับรองจาก Let’s Encrypt มีอายุ 90 วัน | ตั้งค่าการอัปเดตอัตโนมัติ (ใช้ crontab สำหรับงานที่ตั้งเวลา) |
| ยืนยันสิทธิ์ของโดเมนเท่านั้น | ชื่อบริษัทไม่แสดงในแถบที่อยู่ | อัปเกรดเป็นใบรับรอง OV สำหรับเว็บไซต์ธุรกิจ (เริ่มต้นที่ 300 หยวนต่อปี) |
| จำกัดโดเมนเดียว | บางผู้ให้บริการโฮสติ้งมีข้อจำกัดจำนวนโดเมนที่เชื่อมโยง | ใช้ใบรับรอง Wildcard (*.domain.com) |
ปัญหา “Mixed Content” ที่ต้องตรวจสอบ
”ทำไมเว็บไซต์ยังคงแสดงว่าไม่ปลอดภัยหลังจากติดตั้งใบรับรอง SSL?” — ปัญหาที่ใหญ่ที่สุดที่เจ้าของเว็บไซต์ถึง78% ยังคงพบหลังจากตั้งค่า HTTPS (แหล่งที่มา: SSL Labs)
สาเหตุหลักคือ “Mixed Content” นั่นเอง เมื่อมีหมึกหยดลงในน้ำสะอาด มันจะทำให้ทั้งสิ่งนั้นปนเปื้อนเหมือนกับการที่การเข้ารหัสถูกทำลาย
1. ผลกระทบที่ร้ายแรงของ Mixed Content
- ความน่าเชื่อถือที่ลดลง：แม้เว็บไซต์จะปลอดภัย แต่เบราว์เซอร์จะขึ้นสัญลักษณ์เตือนสีเหลือง（Chrome 94 ขึ้นไปจะแสดงเป็นสีแดง）
- ฟังก์ชันผิดพลาด：บางเบราว์เซอร์อาจบล็อกทรัพยากร HTTP ทำให้ภาพไม่แสดงหรือเกิดข้อผิดพลาด JS
- เสียเปรียบในการ SEO：Google จะถือหน้าเพจที่มี Mixed Content เป็น “ปลอดภัยบางส่วน” และลดอันดับการค้นหา 11%-15% （จากข้อมูลการทดสอบของ Ahrefs）
2. วิธีการค้นหาสาเหตุใน 3 นาที
วิธีที่ 1: ใช้เครื่องมือ Developer ของ Chrome
- เปิดเว็บไซต์แล้วกด F12 เพื่อเข้าไปที่เครื่องมือพัฒนา
- เปลี่ยนไปที่ Console Panel เพื่อดูข้อความแสดงข้อผิดพลาดที่เป็นสีแดง
- คลิกที่ลิงก์ในข้อความแสดงข้อผิดพลาดเพื่อไปที่ Sources Panel และหาตำแหน่งของโค้ดที่มีปัญหา
วิธีที่ 2: เครื่องมือสแกนจากบุคคลที่สาม
- Why No Padlock: ใส่ URL และระบบจะสร้างรายการทรัพยากรที่มีปัญหาภายใน 5 วินาที
- Jitbit SSL Check: สแกนลิงก์ภายใน CSS/JS อย่างลึกซึ้ง
วิธีที่ 3: การค้นหาทั่วทั้งฐานข้อมูล
สำหรับระบบสร้างเว็บไซต์เช่น WordPress/Shopify ควรตรวจสอบเนื้อหาประวัติในฐานข้อมูล:
-- ค้นหาลิงก์ HTTP (แทนที่ your_db_prefix ด้วย prefix ของตารางจริง)
SELECT * FROM your_db_prefix_posts
WHERE post_content LIKE '%http://%' AND post_status='publish'; 3. แหล่งที่มาของการปนเปื้อนที่พบบ่อยและวิธีการแก้ไข
| ประเภทปัญหา | อัตราส่วน | กรณีตัวอย่าง | วิธีการแก้ไข |
|---|---|---|---|
| ลิงก์ภาพจากภายนอก | 52% | ภาพที่แนบในบทความที่อัพโหลดก่อนปี 2018 | ดาวน์โหลดภาพและอัพโหลดไปที่ CDN ของเว็บไซต์ |
| โค้ดจากบุคคลที่สาม | 23% | สคริปต์สำหรับหน้าต่างแชทลูกค้า, สคริปต์จากเครือข่ายโฆษณา | ติดต่อผู้ให้บริการเพื่อขอรหัสเวอร์ชัน HTTPS |
| ธีม/ปลั๊กอิน | 17% | ฟอนต์จากไลบรารีเก่า หรือคำขอ AJAX ของธีมเก่า | อัพเดตปลั๊กอินหรือเปลี่ยน http:// เป็น // ด้วยตัวเอง |
| การตั้งค่าฐานข้อมูลแบบฮาร์ดโค้ด | 8% | ลิงก์วิดีโอที่แทรกด้วยตนเองในหน้ารายละเอียดสินค้า | แทนที่ข้อมูลใน SQL อย่างเป็นกลุ่ม (ใช้ปลั๊กอินเพื่อความปลอดภัย) |
4. กลยุทธ์ป้องกันปัญหาการปนเปื้อนถาวร
- ลิงก์ที่สัมพันธ์กับโปรโตคอล: เปลี่ยน
http://example.com/image.jpgเป็น//example.com/image.jpg - นโยบายความปลอดภัยของเนื้อหา (CSP): เพิ่มบรรทัดนี้ในการตั้งค่า Nginx/Apache ของคุณ:
add_header Content-Security-Policy "upgrade-insecure-requests"; การบังคับให้เว็บไซต์ทั้งหมดเปลี่ยนไปใช้ HTTPS (ตัวอย่างโค้ด)
“ทำไมฉันติดตั้งใบรับรอง SSL แล้ว แต่ผู้ใช้ยังสามารถเข้าถึงเวอร์ชัน HTTP ได้?” — นี่คือ จุดอ่อนที่อันตรายที่สุด หลังจากที่ได้แก้ไขปัญหาการปนเปื้อนแล้ว
ร้านค้าออนไลน์สินค้าสำหรับเด็กบางร้านเกิดปัญหาที่ไม่ได้ตั้งค่าการเปลี่ยนเส้นทางอย่างบังคับ ทำให้ผู้ใช้งานบนมือถือ 40% ยังคงเข้าถึงผ่านลิงก์ HTTP เก่า ทำให้ Google เก็บข้อมูลซ้ำและอันดับการค้นหาตกลงไป 30%
หลักการของการบังคับการเปลี่ยนเส้นทางคือ: หยุดการร้องขอ HTTP ทั้งหมด และใช้รหัสสถานะ 301 เปลี่ยนเส้นทางไปยัง HTTPS.
1. เทมเพลตโค้ดทั่วไป (รองรับ Apache/Nginx/IIS)
Apache Server (.htaccess)
RewriteEngine On
# การบังคับเปลี่ยนเส้นทางไปยังโดเมนหลัก
RewriteCond %{HTTPS} !=on
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]
# แก้ไขการใช้งาน www และ non-www
RewriteCond %{HTTP_HOST} !^www\. [NC]
RewriteRule ^(.*)$ https://www.%{HTTP_HOST}%{REQUEST_URI} [L,R=301] สถานการณ์ที่ใช้ได้: โฮสติ้งเสมือน, WordPress, Joomla และเว็บไซต์ PHP อื่น ๆ
คำแนะนำในการหลีกเลี่ยงปัญหา:
- ตรวจสอบให้แน่ใจว่าเซิร์ฟเวอร์เปิดใช้งานโมดูล
mod_rewriteแล้ว - ไฟล์ต้องอัปโหลดไปที่โฟลเดอร์รากของเว็บไซต์
- หากการเปลี่ยนเส้นทางล้มเหลว ให้ตรวจสอบว่ามี
.htaccessไฟล์หลายไฟล์ที่ทำให้เกิดความขัดแย้งหรือไม่
เซิร์ฟเวอร์ Nginx (ส่วนการตั้งค่า nginx.conf)
server {
listen 80;
server_name example.com www.example.com;
# การเปลี่ยนเส้นทาง 301 ไปยังทั้งเว็บไซต์
return 301 https://$server_name$request_uri;
# การห้ามวิธีการ HTTP ที่ไม่ปลอดภัย
if ($request_method !~ ^(GET|HEAD|POST)$ ) {
return 444;
}
} เคล็ดลับการดีบัก:
- หลังจากการแก้ไข ใช้คำสั่ง
nginx -tเพื่อตรวจสอบไวยากรณ์การตั้งค่า - โหลดการตั้งค่าใหม่:
nginx -s reload - ห้ามวิธีการ HTTP ที่ไม่จำเป็น เพื่อป้องกันการรั่วไหลของข้อมูล
เซิร์ฟเวอร์ Windows IIS (กฎ web.config)
<configuration>
<system.webServer>
<rewrite>
<rules>
<rule name="Force HTTPS" stopProcessing="true">
<match url="(.*)" />
<conditions>
<add input="{HTTPS}" pattern="^OFF$" />
</conditions>
<action type="Redirect" url="https://{HTTP_HOST}/{R:1}" redirectType="Permanent" />
</rule>
</rules>
</rewrite>
</system.webServer>
</configuration>
ข้อผิดพลาดทั่วไป：
- IIS ไม่มีการติดตั้ง “URL Rewrite” โมดูล → ลิงก์ดาวน์โหลดทางการ
- การเข้ารหัสเส้นทางภาษาจีนผิดพลาด → เพิ่ม
encode="false"ในกฎ
2. โซลูชันเฉพาะสำหรับ CMS
ผู้ใช้ WordPress
- เข้าสู่ระบบแผงผู้ดูแลระบบ → การตั้งค่า → ทั่วไป
- เปลี่ยน ที่อยู่ WordPress และ ที่อยู่เว็บไซต์ จาก
http://เป็นhttps:// - ติดตั้งปลั๊กอิน Really Simple SSL → แก้ไขเนื้อหาผสมในฐานข้อมูลด้วยคลิกเดียว
Shopify/Laravel และเฟรมเวิร์กอื่นๆ
บังคับใช้ HTTPS ในไฟล์ตัวแปรสภาพแวดล้อม (.env):
APP_URL=https://www.example.com
FORCE_SSL=true
SESSION_SECURE_COOKIE=true
3. การจัดการพิเศษสำหรับมือถือ (AMP/WeChat Browser)
- การเปลี่ยนเส้นทาง AMP: เพิ่ม
<meta http-equiv="refresh" content="0; url=https://ลิงก์ใหม่">ใน AMP HTML - ปัญหาค่าแคชของ WeChat: เพิ่มพารามิเตอร์สุ่มที่ส่วนท้ายของ URL เช่น
?v=2024เพื่อบังคับให้รีเฟรชเวอร์ชัน HTTPS
4. ทดสอบการทำงานของการเปลี่ยนเส้นทาง
ทดสอบในเบราว์เซอร์:
- ไปที่
http://example.com→ แถบที่อยู่ควรเปลี่ยนเป็นhttps://โดยอัตโนมัติ - ตรวจสอบว่าไอคอนรูปแม่กุญแจหลังจากการเปลี่ยนเส้นทางเป็นสีเขียวหรือไม่
ตรวจสอบด้วยบรรทัดคำสั่ง:
curl -I http://example.com
# การตอบกลับที่ถูกต้องควรมีดังนี้:
# HTTP/1.1 301 Moved Permanently
# Location: https://example.com เครื่องมือออนไลน์:
คำเตือนข้อผิดพลาด:
การกำหนดค่าผิดพลาด → ลูปการเปลี่ยนเส้นทางไม่สิ้นสุด (ERR_TOO_MANY_REDIRECTS)
สาเหตุที่พบบ่อย:
1. CDN ใช้การเปลี่ยนเส้นทาง HTTPS พร้อมกัน (ขัดแย้งกับกฎของเซิร์ฟเวอร์)
2. ตัวโหลดบาลานเซอร์ไม่ได้ส่งผ่านโปรโตคอลเฮดเดอร์อย่างถูกต้อง
วิธีแก้ไข:
เพิ่มบรรทัดนี้ในการตั้งค่า Nginx:
proxy_set_header X-Forwarded-Proto $scheme; หลักการเปลี่ยนเส้นทางที่เป็นมิตรกับ SEO:
- ใช้ 301 รีไดเร็กต์ ทั่วทั้งเว็บไซต์ (รีไดเร็กต์ถาวร) เพื่อถ่ายโอนมูลค่าลิงก์ 100%
- หลีกเลี่ยงการเปลี่ยนเส้นทางแบบลูกโซ่ (เช่น http→http://www→https) จำกัดให้มีการเปลี่ยนเส้นทางสูงสุด 1 ครั้ง
- ส่งแผนผังเว็บไซต์เวอร์ชัน HTTPS ไปยัง Google Search Console
ตั้งแต่ปี 2018 Google ได้เริ่มทำ HTTPS เป็นหนึ่งในปัจจัยในการจัดอันดับการค้นหา เว็บไซต์ที่ไม่มีการเข้ารหัสจะสูญเสียทราฟฟิกเฉลี่ยถึง 12%-15% ทุกปี และการสูญเสียนี้จะเพิ่มขึ้นตามการรับรู้ด้านความปลอดภัยของผู้ใช้
