SSL HTTPS สำคัญกับ SEO ยังไง ต้องทำแค่ไหนถึงพอ

HTTPS เป็นปัจจัยจัดอันดับของ Google จริงไหม

จริง Google ยืนยันเองในประกาศปี 2014 ว่า HTTPS เป็นหนึ่งในสัญญาณจัดอันดับ แต่ในประกาศเดียวกันก็ระบุว่าเป็นสัญญาณน้ำหนักเบา (lightweight signal) ที่ส่งผลกับผลการค้นหาเพียงส่วนน้อย และให้ความสำคัญกับคุณภาพเนื้อหามาก่อนเสมอ

แปลเป็นภาษาคนทำเว็บคือ HTTPS เป็นปัจจัยจัดอันดับจริง แต่เป็นสัญญาณเบา ที่ทำหน้าที่คล้ายตัวตัดสินเมื่อทุกอย่างอื่นเท่ากันมากกว่าจะเป็นตัวผลักอันดับ การติด SSL วันนี้แล้วคาดหวังว่าพรุ่งนี้อันดับจะขยับเป็นความคาดหวังที่ผิด เพราะเนื้อหาที่ตอบคำถามได้ตรงกว่า ประสบการณ์ใช้งานที่ดีกว่า และสัญญาณความน่าเชื่อถือของเว็บ ยังมีน้ำหนักมากกว่ามาก

แต่ต้องมองอีกด้านด้วย เมื่อเว็บส่วนใหญ่ในผลค้นหาย้ายมาใช้ HTTPS กันหมดแล้ว การไม่มี HTTPS ไม่ได้แค่ขาดคะแนนเล็ก ๆ แต่ทำให้เว็บกลายเป็นตัวประหลาดในหน้าผลการค้นหา และเจอผลกระทบทางอ้อมอีกชุดใหญ่ที่อธิบายในหัวข้อถัดไป

• Google ประกาศ HTTPS เป็นสัญญาณจัดอันดับตั้งแต่ปี 2014
• เป็นสัญญาณน้ำหนักเบา ไม่ใช่ตัวชี้ขาดว่าใครขึ้นอันดับหนึ่ง
• มี SSL แล้วไม่ได้แปลว่าอันดับจะดีขึ้นทันที
• ไม่มี SSL เสียเปรียบทั้งด้านสัญญาณและด้านความเชื่อมั่นของผู้ใช้

เว็บที่ยังเป็น HTTP อยู่ เสียอะไรบ้าง

เสียมากกว่าคะแนนจัดอันดับที่หายไปนิดเดียว เพราะผลกระทบหลักเกิดกับผู้ใช้และกับเครื่องมือรอบตัวเว็บ ไม่ใช่กับอัลกอริทึมโดยตรง

ชัดที่สุดคือป้ายเตือนบนเบราว์เซอร์ Chrome และเบราว์เซอร์อื่นแสดงข้อความว่าไม่ปลอดภัยกับหน้า HTTP ทุกหน้าอยู่แล้วตั้งแต่ปี 2018 และเตือนหนักขึ้นอีกระดับกับหน้าที่มีช่องกรอกข้อมูล เช่น ฟอร์มติดต่อ ฟอร์มขอใบเสนอราคา หรือหน้าเข้าสู่ระบบ ผู้ใช้ที่เห็นคำเตือนตอนกำลังจะกรอกเบอร์โทรมักกดปิดทันที มีแนวโน้มทำให้อัตราการติดต่อกลับลดลงและค่า bounce rate สูงขึ้นได้ ซึ่งเป็นปัญหาที่แก้ด้วยการปรับเนื้อหาอย่างเดียวไม่ได้

อีกด้านคือข้อจำกัดทางเทคนิค ฟีเจอร์เว็บสมัยใหม่หลายอย่างต้องการ secure context ถึงจะทำงาน เช่น การขอตำแหน่งที่ตั้ง การใช้กล้อง หรือ service worker และ HTTP/2 กับ HTTP/3 ที่ช่วยเรื่องความเร็วก็ใช้งานจริงบน HTTPS เท่านั้นในทางปฏิบัติ เมื่อโหลดช้ากว่าก็พาลกระทบประสบการณ์หน้าเว็บที่ Google ใช้วัดผ่าน Core Web Vitals ต่อไปอีกทอด

สุดท้ายคือข้อมูลใน Analytics เมื่อผู้ใช้กดจากเว็บ HTTPS มายังเว็บ HTTP ข้อมูลแหล่งที่มามักหลุดหายกลายเป็น direct ทำให้อ่านรายงานผิด และประเมินคุณค่าของช่องทางที่ส่ง traffic มาต่ำกว่าความจริง

ย้ายจาก HTTP ไป HTTPS ยังไงไม่ให้เสีย SEO

หัวใจคือทำให้ Google เข้าใจว่านี่คือเว็บเดิมที่ย้ายที่อยู่ถาวร ไม่ใช่เว็บใหม่ที่มีเนื้อหาซ้ำกับของเก่า ทำได้ด้วยการ redirect ทุก URL แบบหนึ่งต่อหนึ่ง แล้วทำให้สัญญาณอื่น ๆ ทั้งหมดชี้ไปที่เวอร์ชัน HTTPS อย่างสอดคล้องกัน

งานนี้คล้ายกับการย้ายโดเมนแบบย่อส่วน หลักการเดียวกับที่ใช้ใน คู่มือย้ายโดเมนโดยไม่ให้อันดับหาย แค่เปลี่ยนจากคนละชื่อโดเมนเป็นคนละโปรโตคอล ลำดับที่แนะนำมีดังนี้

• 301 หนึ่งต่อหนึ่งทุก URL ไม่ยิงรวมไปหน้าแรก
• canonical ทุกหน้าชี้ HTTPS
• sitemap.xml และ robots.txt ใช้ URL แบบ HTTPS
• internal link ชี้ตรงไม่ผ่าน redirect
• เพิ่ม property HTTPS ใน Search Console แล้วส่ง sitemap ใหม่
• อัปเดตลิงก์ในเครื่องมือภายนอก เช่น โฆษณา อีเมล และโปรไฟล์โซเชียล

1. ติดตั้งใบรับรองและทดสอบก่อนเปิดใช้จริง

ติดตั้งใบรับรองบนเซิร์ฟเวอร์แล้วเปิด HTTPS ให้เข้าถึงได้ก่อน โดยยังไม่บังคับ redirect จากนั้นเปิดหน้าเว็บทีละแบบด้วย https:// ตรง ๆ เพื่อดูว่าหน้าแสดงผลครบไหม รูปขึ้นครบไหม ฟอร์มยังส่งได้ไหม

ตรวจด้วยว่าใบรับรองครอบคลุมทุกชื่อโฮสต์ที่ใช้จริง ทั้งแบบมี www และไม่มี www รวมถึงซับโดเมนที่ให้บริการหน้าเว็บสาธารณะ เพราะใบรับรองที่ครอบคลุมไม่ครบจะทำให้บางหน้าขึ้นคำเตือนซึ่งแย่กว่าไม่ติดตั้งเลย

2. แก้ mixed content ให้หมดก่อน แล้วค่อยบังคับ redirect

ไล่แก้ทรัพยากรที่ยังเรียกผ่าน http:// ให้หมดก่อนเปิดใช้จริง ทั้งรูป ไฟล์ CSS ไฟล์ JavaScript ฟอนต์ และ iframe เพราะถ้าเปิด HTTPS ทั้งเว็บทั้งที่ยังมี mixed content ผู้ใช้จะเจอหน้าที่ดีไซน์พังหรือสคริปต์ไม่ทำงาน

วิธีที่เร็วที่สุดคือแก้ที่ต้นทางในฐานข้อมูลและในเทมเพลต ให้เรียกทรัพยากรแบบระบุ https:// ตรง ๆ หรือใช้ path แบบสัมพัทธ์ แล้วค่อยเปิดกฎ redirect ทั้งเว็บ

3. ทำ 301 redirect ทั้งเว็บแบบหนึ่งต่อหนึ่ง

ตั้งกฎที่เซิร์ฟเวอร์ให้ทุก URL บน HTTP วิ่งไปยัง URL เดียวกันบน HTTPS ด้วยสถานะ 301 แบบถาวร 1 ต่อ 1 ห้ามยิงทุกหน้ารวมไปที่หน้าแรก เพราะจะทำให้หน้าที่เคยมีอันดับหายไปทั้งชุดพร้อมกับสัญญาณลิงก์ที่สะสมมา

อย่าใช้ 302 กับการย้ายถาวรแบบนี้ เพราะสื่อความหมายว่าเป็นการย้ายชั่วคราว เหตุผลเชิงลึกเรื่องความแตกต่างอยู่ในบทความ 301 กับ 302 ต่างกันยังไงและควรใช้ตอนไหน

ระวังอีกจุดคือ redirect ซ้อนกันหลายชั้น เช่น จาก http ไป http แบบมี www แล้วค่อยไป https การไล่ทีละทอดทำให้ช้าและเปลืองงบการรวบรวมข้อมูล ควรตั้งกฎให้จบภายในการ redirect ครั้งเดียว

4. อัปเดต canonical, sitemap และ internal link

แก้ canonical tag ทุกหน้าให้ชี้ไปยัง URL แบบ HTTPS ถ้าปล่อยให้ canonical ยังชี้ HTTP เท่ากับบอก Google ด้วยตัวเองว่าเวอร์ชันหลักคือเวอร์ชันเก่า ซึ่งขัดกับ redirect ที่เพิ่งตั้งไป รายละเอียดการใช้แท็กนี้อ่านได้ใน คู่มือ canonical tag

จากนั้นสร้าง sitemap.xml ใหม่ที่มีเฉพาะ URL แบบ HTTPS และตรวจ robots.txt ว่าบรรทัด Sitemap ชี้ไปยังไฟล์บน HTTPS แล้ว

สุดท้ายคือลิงก์ภายในเว็บ อย่าปล่อยให้ internal link วิ่งผ่าน redirect ให้แก้ในเนื้อหา เมนู ฟุตเตอร์ และ hreflang ให้ชี้ HTTPS ตรง ๆ ทั้งหมด รวมถึงลิงก์ในไฟล์ CSS และ JavaScript ที่มักถูกลืม

5. เพิ่ม property ใหม่ใน Google Search Console และเฝ้าดู

ถ้าใช้ property แบบ URL-prefix Search Console จะมองว่า http:// กับ https:// เป็นคนละ property ต้องเพิ่ม property ของเวอร์ชัน HTTPS เข้าไปใหม่แล้วส่ง sitemap ชุดใหม่ที่นั่น แต่ถ้าใช้ property แบบ Domain ระบบจะครอบทุกโปรโตคอลและซับโดเมนไว้ในตัวเดียวอยู่แล้ว ไม่ต้องเพิ่มใหม่

เก็บ property เดิม (กรณีใช้แบบ URL-prefix) ไว้ด้วยอย่างน้อยสองสามเดือน เพื่อดูว่าการเก็บข้อมูลหน้าเก่าลดลงตามที่ควรเป็นไหม และไม่มี URL เก่าค้างที่ยังถูกจัดทำดัชนีอยู่

mixed content คืออะไร และแก้ยังไง

mixed content คือกรณีที่หน้าเว็บเปิดผ่าน HTTPS แล้ว แต่ยังดึงทรัพยากรบางอย่างมาผ่าน HTTP เช่น รูปภาพ ไฟล์สคริปต์ หรือฟอนต์ ผลคือเบราว์เซอร์ถือว่าหน้านั้นไม่ปลอดภัยเต็มร้อย จึงเตือนหรือบล็อกทรัพยากรนั้นทิ้งไปเลย

mixed content แบ่งเป็นสองระดับ ระดับ passive คือรูปหรือวิดีโอ เบราว์เซอร์สมัยใหม่จะพยายาม auto-upgrade ให้โหลดผ่าน HTTPS ให้เองก่อน ถ้าอัปเกรดไม่สำเร็จก็บล็อกทิ้งจนรูปหรือวิดีโอนั้นหายไปเลย ไม่ใช่แค่ลดสถานะความปลอดภัยเฉยๆ เหมือนก่อนหน้านี้ ส่วนระดับ active คือ JavaScript, CSS หรือ iframe ซึ่งอันตรายกว่า เพราะแก้ไขหน้าเว็บได้ เบราว์เซอร์จึงบล็อกทิ้งทันทีไม่มีข้อยกเว้น ผลที่เห็นคือเมนูกดไม่ได้ สไลด์ไม่เลื่อน หรือหน้าเว็บเสียรูปทั้งหน้า

วิธีหาคือเปิด DevTools ที่แท็บ Console แล้วดูข้อความเตือนเรื่อง mixed content หรือใช้เครื่องมือไล่คลานทั้งเว็บเพื่อหา URL ที่ยังขึ้นต้นด้วย http:// ในซอร์สโค้ด สำหรับเว็บที่มีเนื้อหาเก่าจำนวนมาก การค้นแล้วแทนที่ในฐานข้อมูลจะเร็วกว่าไล่แก้ทีละหน้ามาก

จุดที่คนลืมบ่อยคือลิงก์ที่ฝังอยู่ในไฟล์ CSS, โค้ดของธีมหรือปลั๊กอิน, สคริปต์ของบุคคลที่สาม และ URL ในฐานข้อมูลที่มาจากการอัปโหลดรูปสมัยยังเป็น HTTP ทั้งหมดนี้ต้องไล่ให้ครบ ไม่ใช่ดูแค่หน้าแรก

• passive mixed content เช่น รูป วิดีโอ ทำให้สถานะหน้าลดลง
• active mixed content เช่น JS, CSS, iframe มักถูกบล็อกจนหน้าพัง
• ตรวจได้จาก Console ใน DevTools หรือเครื่องมือไล่คลานทั้งเว็บ
• แก้ที่ต้นทางในฐานข้อมูลและเทมเพลต ไม่ใช่ปะทีละหน้า
• อย่าลืมสคริปต์ของบุคคลที่สามและไฟล์ธีมเก่า

HSTS คืออะไร จำเป็นต้องเปิดไหม

HSTS หรือ HTTP Strict Transport Security คือ HTTP header ที่บอกเบราว์เซอร์ว่าให้เชื่อมต่อกับโดเมนนี้ผ่าน HTTPS เสมอ แม้ผู้ใช้จะพิมพ์ http:// หรือกดลิงก์เก่ามาก็ตาม ประโยชน์คือปิดช่องโหว่ที่ผู้ไม่หวังดีดักการเชื่อมต่อครั้งแรกแล้วบังคับให้ตกกลับไปใช้ HTTP

ในแง่ SEO โดยตรง HSTS ไม่ใช่ปัจจัยจัดอันดับ แต่ช่วยทางอ้อมด้วยการตัด redirect หนึ่งทอดออกไป เพราะเบราว์เซอร์จะไปที่ HTTPS ตั้งแต่แรกโดยไม่ต้องรอเซิร์ฟเวอร์ตอบ 301 ทำให้หน้าเปิดเร็วขึ้นเล็กน้อยสำหรับผู้ใช้ที่กลับมาซ้ำ

ข้อควรระวังคือ HSTS มีอายุกำหนดไว้ใน max-age และเบราว์เซอร์จะจำไว้จนกว่าจะหมดอายุ ถ้าตั้งค่าอายุยาวแล้วใบรับรองมีปัญหาภายหลัง ผู้ใช้จะเข้าเว็บไม่ได้เลยและกดข้ามคำเตือนไม่ได้ด้วย จึงควรเริ่มจากค่าอายุสั้นก่อน เช่น ไม่กี่ชั่วโมงหรือไม่กี่วัน ทดสอบจนมั่นใจแล้วค่อยขยับขึ้น

ส่วนการส่งโดเมนเข้า HSTS preload list ที่ฝังมากับตัวเบราว์เซอร์นั้น ห้ามเปิด preload ตั้งแต่วันแรก เพราะการถอนออกใช้เวลานานหลายเดือน ควรทำเมื่อ HTTPS ทั้งเว็บรวมถึงทุกซับโดเมนเสถียรแล้วเท่านั้น

ใบรับรอง SSL แบบไหนพอสำหรับ SEO

DV ก็เพียงพอสำหรับ SEO เพราะ Google ไม่ได้แยกแยะระดับของใบรับรอง สิ่งที่ระบบมองคือหน้าเว็บให้บริการผ่าน HTTPS ที่ใช้งานได้จริงหรือไม่ ใบรับรองแบบฟรีจากผู้ให้บริการที่เชื่อถือได้จึงให้ผลด้าน SEO ไม่ต่างจากใบรับรองราคาแพง

ความต่างของ DV, OV และ EV อยู่ที่ระดับการตรวจสอบตัวตนขององค์กร ไม่ใช่ความแข็งแรงของการเข้ารหัส ธุรกิจการเงิน โรงพยาบาล หรือองค์กรที่ต้องแสดงตัวตนชัดเจนอาจเลือก OV หรือ EV เพื่อเหตุผลด้านการกำกับดูแลและความน่าเชื่อถือขององค์กร แต่ไม่ควรซื้อโดยคาดหวังว่าจะได้อันดับเพิ่ม

สิ่งที่สำคัญกว่าประเภทใบรับรองคือความต่อเนื่อง ใบรับรองที่หมดอายุแล้วไม่มีใครต่อ ทำให้เบราว์เซอร์ขึ้นหน้าเตือนเต็มจอ ผู้ใช้เข้าไม่ได้ และบอตก็เก็บข้อมูลไม่ได้เช่นกัน ควรตั้งระบบต่ออายุอัตโนมัติและตั้งการแจ้งเตือนก่อนหมดอายุไว้เสมอ

• Google ไม่ได้ให้คะแนนต่างกันตามระดับใบรับรอง
• ความแข็งแรงของการเข้ารหัสไม่ได้ขึ้นกับราคาใบรับรอง
• เลือก OV หรือ EV ด้วยเหตุผลด้านองค์กร ไม่ใช่ด้านอันดับ
• ใบรับรองหมดอายุคือความเสี่ยงที่ใหญ่กว่าการเลือกประเภทผิด

ทำไมย้ายเป็น HTTPS แล้วอันดับตก

ส่วนใหญ่ไม่ได้ตกเพราะ HTTPS แต่ตกเพราะขั้นตอนการย้ายไม่ครบ และบางส่วนเป็นความผันผวนชั่วคราวที่กลับมาเองเมื่อ Google เก็บข้อมูลเวอร์ชันใหม่ครบแล้ว

สาเหตุที่เจอบ่อยที่สุดคือ redirect ไม่ครบทุกหน้า หรือทำแบบยิงรวมไปหน้าแรก ทำให้หน้าที่เคยมีอันดับกลายเป็น 404 ไปพร้อมกัน รองลงมาคือ canonical ยังชี้ HTTP ทำให้สัญญาณขัดแย้งกันเอง และการเผลอปล่อยไฟล์ robots.txt เวอร์ชันทดสอบที่บล็อกทั้งเว็บขึ้นเซิร์ฟเวอร์จริง

อีกกรณีที่มองข้ามคือความเร็วที่ลดลงหลังย้าย เพราะ redirect ซ้อนหลายชั้นหรือเซิร์ฟเวอร์ตั้งค่า TLS ไม่ดี ถ้าเว็บช้าลงชัดเจน ประสบการณ์ผู้ใช้ก็แย่ลงตาม การไล่ตรวจตาม เช็กลิสต์ Technical SEO หลังย้ายเสร็จจะช่วยจับปัญหาพวกนี้ได้เร็ว

สุดท้ายต้องตั้งความคาดหวังให้ถูก อันดับสั่นไหวช่วงสั้น ๆ หลังย้ายเป็นเรื่องปกติ เพราะระบบต้องเก็บข้อมูลและย้ายสัญญาณจาก URL เก่ามาใหม่ ระยะเวลาขึ้นกับขนาดเว็บและความถี่ในการเก็บข้อมูล สิ่งที่ควรทำคือเฝ้าดูข้อมูลจริงในรายงาน ไม่ใช่รีบแก้กลับไปมาจนสัญญาณยิ่งสับสน

ความเข้าใจผิดเรื่อง SSL กับ SEO ที่ได้ยินบ่อย

ความเข้าใจผิดที่พบบ่อยที่สุดคือคิดว่าติด SSL แล้วอันดับจะดีขึ้นเอง ทั้งที่มันคือคุณสมบัติพื้นฐานที่คู่แข่งเกือบทุกรายมีอยู่แล้ว จึงเป็นการทำให้ทัดเทียมมากกว่าการสร้างข้อได้เปรียบ

อีกข้อคือเข้าใจว่ากดเปิด SSL ที่โฮสต์แล้วจบ ความจริงงานส่วนใหญ่อยู่หลังจากนั้น ทั้ง redirect, canonical, sitemap, ลิงก์ภายใน และการไล่ mixed content ซึ่งเป็นงานที่ตรวจไม่ครบแล้วเสียหายจริง

ที่เหลือคือความเชื่อปลีกย่อยที่ทำให้เสียเงินหรือเสียเวลาโดยไม่จำเป็น

• ใบรับรองแพงกว่าไม่ได้ทำให้อันดับดีกว่า
• SSL ไม่ได้ป้องกันการแฮ็กเว็บ แค่เข้ารหัสข้อมูลระหว่างทาง
• เว็บที่ไม่มีฟอร์มก็ยังควรใช้ HTTPS เพราะเบราว์เซอร์และผู้ใช้คาดหวังแบบนั้น
• การย้ายเป็น HTTPS ไม่ใช่การเปลี่ยนเว็บใหม่ ถ้าทำ 301 ครบ สัญญาณเดิมจะย้ายตามมา
• การเปิด HSTS ไม่ได้แทนที่การทำ 301 redirect ที่ฝั่งเซิร์ฟเวอร์

เช็กลิสต์ตรวจหลังย้ายเป็น HTTPS

หลังเปิด HTTPS ใช้จริง ควรมีรอบตรวจอย่างน้อยสองครั้ง คือวันแรกเพื่อจับปัญหาที่ทำให้เว็บพัง และอีกครั้งหลังผ่านไปหนึ่งถึงสองสัปดาห์เพื่อดูว่าการเก็บข้อมูลและการจัดทำดัชนีย้ายตามมาครบไหม

ระหว่างนั้นให้ดูรายงานใน Search Console เป็นหลัก โดยเฉพาะหน้าที่ถูกจัดทำดัชนี หน้าที่ถูกยกเว้น และรายงานประสบการณ์หน้าเว็บ แล้วเทียบกับข้อมูลก่อนย้ายเพื่อดูแนวโน้ม ไม่ใช่ดูตัวเลขวันเดียวแล้วสรุป

ถ้าเว็บมีขนาดใหญ่หรือมีโครงสร้าง URL ซับซ้อน การให้คนนอกไล่ตรวจซ้ำอีกรอบช่วยลดจุดที่มองข้ามได้มาก ซึ่งเป็นส่วนหนึ่งของงาน ตรวจสุขภาพเว็บเชิงเทคนิค ที่ SEONo1 ทำให้ลูกค้าอยู่แล้ว

• เปิดหน้าเว็บทุกประเภทด้วย HTTPS แล้วดูว่าไม่มีคำเตือนใน Console
• ทดสอบว่า URL เก่าทุกแบบ redirect ไปหน้าที่ถูกต้องด้วย 301 ครั้งเดียว
• ตรวจ canonical, hreflang และ Open Graph ว่าใช้ HTTPS ทั้งหมด
• ส่ง sitemap ใหม่และเฝ้าดูจำนวนหน้าที่ถูกจัดทำดัชนี
• อัปเดต URL ปลายทางของโฆษณาและลิงก์ในโปรไฟล์ภายนอก
• ตรวจว่าใบรับรองต่ออายุอัตโนมัติได้จริงก่อนถึงวันหมดอายุ