Skip to main content
← Back to blog

คู่มือ SEO ขั้นตอนที่ 7: ความปลอดภัย — มาตรฐานพื้นฐานที่ Google คาดหวังในปี 2026

·7 min read·by LANGR SEO

คู่มือ SEO ขั้นตอนที่ 7: ความปลอดภัย

นี่คือขั้นตอนที่ 7 ของ คู่มือ SEO 13 ขั้นตอน. ความปลอดภัยไม่ใช่แค่การปกป้องผู้ใช้ — มันมีผลโดยตรงต่ออันดับการค้นหาของคุณ Google ได้ใช้ HTTPS เป็นสัญญาณอันดับตั้งแต่ปี 2014 และความคาดหวังได้เพิ่มขึ้นเรื่อย ๆ.

เจ้าของเว็บไซต์ส่วนใหญ่คิดว่าความปลอดภัยเป็นเรื่องแบบสองทาง: "เรามี SSL ดังนั้นเราจึงปลอดภัย" ในความเป็นจริง Google ประเมินสัญญาณความปลอดภัยต่าง ๆ นับสิบ เว็บไซต์ที่มีหัวข้อตามหลักที่เหมาะสม, ใบรับรองที่ถูกต้อง, และไม่มีเนื้อหาผสมจะมีอันดับสูงกว่าเว็บไซต์ที่มีแค่ใบรับรอง SSL พื้นฐาน — เมื่อพิจารณาความเท่าเทียมในทุกด้าน

ข่าวดี: การแก้ไขความปลอดภัยส่วนใหญ่เป็นการตั้งค่าครั้งเดียว ตั้งค่าเพียงครั้งเดียวและมันจะปกป้องอันดับของคุณถาวร

การตั้งค่า SSL

SSL (ทางเทคนิคคือ TLS) เข้ารหัสการเชื่อมต่อระหว่างเซิร์ฟเวอร์ของคุณกับผู้เยี่ยมชม ตั้งแต่ปี 2014 Google ได้ยืนยันว่า HTTPS เป็นสัญญาณอันดับอย่างชัดเจน ในปี 2026 การไม่มี HTTPS ไม่ใช่แค่เรื่องอันดับ — Chrome จะทำเครื่องหมายเว็บไซต์ HTTP ว่า "ไม่ปลอดภัย" ในแถบที่อยู่ ทำลายความไว้วางใจของผู้ใช้

ข้อกำหนดสำหรับ SSL ที่เหมาะสม:

| ข้อกำหนด | ทำไม | วิธีตรวจสอบ | |-----------|------|--------------| | ใบรับรองที่ถูกต้อง | หมดอายุ = ข้อความเตือนในเบราว์เซอร์ = ผู้ใช้หลุด | ตรวจสอบวันหมดอายุ | | โซ่ทั้งหมด | โซ่ที่ไม่สมบูรณ์ล้มเหลวในอุปกรณ์บางประเภท | ทดสอบ SSL Labs | | TLS 1.2+ | เวอร์ชันเก่ามีช่องโหว่ที่ทราบ | ทดสอบ SSL Labs | | ไม่มี SHA-1 | ถูกเลิกใช้ เบราว์เซอร์ปฏิเสธ | รายละเอียดใบรับรอง | | ความครอบคลุม SAN | www และ non-www จะต้องมีการครอบคลุมทั้งคู่ | รายละเอียดใบรับรอง | | การต่ออายุอัตโนมัติ | ป้องกันภัยพิบัติจากการหมดอายุ | Let's Encrypt / การตั้งค่าผู้ให้บริการ |

การให้คะแนน SSL:

100% = ใบรับรองที่ถูกต้อง + โซ่ทั้งหมด + TLS 1.3 + รหัสเข้าที่แข็งแรง + การต่ออายุอัตโนมัติ
  0% = ใบรับรองหมดอายุหรือหายไป

ข้อผิดพลาด SSL ที่พบบ่อย:

  1. ใบรับรองหมดอายุโดยไม่มีการแจ้งเตือน — ตั้งค่าการตรวจสอบ (ขั้นตอนที่ 6) อย่างน้อย 30 วันก่อนวันหมดอายุ
  2. โซ่ใบรับรองไม่สมบูรณ์ — เซิร์ฟเวอร์ต้องส่งใบรับรองที่เป็นกลางไม่เพียงแค่ใบรับรองเล็ก ๆ
  3. เนื้อหาผสม — หน้า HTTPS โหลดทรัพยากร HTTP (รูปภาพ, สคริปต์, สไตล์ชีต)
  4. การวนรอบการเปลี่ยนเส้นทาง — HTTP → HTTPS → HTTP วนรอบเนื่องจาก CDN/พร็อกซีที่กำหนดค่าไม่ถูกต้อง
  5. ความไม่ตรงกันระหว่าง non-www กับ www — ใบรับรองครอบคลุมหนึ่งอันแต่ไม่อีกอัน

ชัยชนะอย่างรวดเร็ว: รันโดเมนของคุณผ่าน SSL Labs (ssllabs.com/ssltest) สิ่งใดที่ต่ำกว่าการให้คะแนน "A" จะต้องแก้ไขปัญหา ที่ผู้ให้บริการโฮสติ้งส่วนใหญ่แก้ไขได้ด้วยการคลิกเพียงครั้งเดียว

หัวข้อความปลอดภัย

หัวข้อความปลอดภัยคือหัวข้อการตอบสนอง HTTP ที่สั่งให้เบราว์เซอร์ทำตัวอย่างไรเมื่อโหลดเว็บไซต์ของคุณ มันป้องกันการโจมตีหลายประเภท — และ Google’s crawlers ตรวจสอบเพื่อให้แน่ใจว่ามีอยู่

หัวข้อความปลอดภัยที่สำคัญ:

นโยบายความปลอดภัยเนื้อหา (CSP)

CSP เป็นหัวข้อความปลอดภัยที่ทรงพลังที่สุด มันบอกเบราว์เซอร์อย่างชัดเจนว่าทรัพยากรใด (สคริปต์, สไตล์, รูปภาพ, ฟอนต์) ที่ได้รับอนุญาตให้โหลดบนหน้าเว็บของคุณ

Content-Security-Policy: default-src 'self'; script-src 'self' https://cdn.example.com; style-src 'self' 'unsafe-inline'; img-src 'self' data: https:; font-src 'self' https://fonts.gstatic.com; connect-src 'self' https://api.example.com; frame-ancestors 'none';

สิ่งที่ CSP ป้องกัน:

  • การโจมตี Cross-site scripting (XSS)
  • การโจมตีการฉีดข้อมูล
  • Clickjacking (ผ่าน frame-ancestors)
  • การดำเนินการสคริปต์โดยไม่ได้รับอนุญาต (cryptominers, ad injectors)

กลยุทธ์การประยุกต์ใช้ CSP:

  1. เริ่มต้นด้วย Content-Security-Policy-Report-Only (บันทึกการละเมิดโดยไม่บล็อก)
  2. ติดตามรายงานเป็นเวลา 1-2 สัปดาห์
  3. เพิ่มแหล่งข้อมูลที่ถูกต้องลงในรายการขาว
  4. เปลี่ยนเป็นโหมดบังคับ
  5. เพิ่ม report-uri หรือ report-to สำหรับการบันทึกการละเมิดอย่างต่อเนื่อง

X-Frame-Options

ป้องกันไม่ให้เว็บไซต์ของคุณถูกฝังใน iframe บนโดเมนอื่น (การป้องกัน clickjacking)

X-Frame-Options: DENY

หรือต้องการอนุญาตให้มีการฝังจากต้นทางเดียวกัน:

X-Frame-Options: SAMEORIGIN

X-Content-Type-Options

ป้องกันไม่ให้เบราว์เซอร์ทำการตรวจจับประเภท MIME (ตีความไฟล์เป็นประเภทที่แตกต่างจากที่ระบุ)

X-Content-Type-Options: nosniff

บรรทัดนี้จะป้องกันการโจมตีที่ไฟล์ .jpg มี JavaScript ที่ซ่อนอยู่ซึ่งเบราว์เซอร์อาจจะดำเนินการ

Referrer-Policy

ควบคุมข้อมูลการอ้างอิงที่ถูกส่งเมื่อผู้ใช้คลิกลิงก์จากเว็บไซต์ของคุณ

Referrer-Policy: strict-origin-when-cross-origin

นี่จะส่ง URL ทั้งหมดสำหรับคำขอที่มาจากต้นทางเดียวกัน แต่จะส่งเพียงต้นทาง (โดเมน) สำหรับคำขอข้ามต้นทาง จึงให้ความสมดุลระหว่างความต้องการวิเคราะห์ข้อมูลและความเป็นส่วนตัว

Permissions-Policy

ควบคุมฟีเจอร์ของเบราว์เซอร์ (กล้อง, ไมโครโฟน, การระบุตำแหน่ง, เป็นต้น) ที่สามารถใช้บนเว็บไซต์ของคุณ

Permissions-Policy: camera=(), microphone=(), geolocation=(), payment=()

การปิดฟีเจอร์ที่ไม่ใช้จะป้องกันไม่ให้สคริปต์จากบุคคลที่สามใช้ประโยชน์จากมัน

ตัวอย่างการโอนการตั้งค่า (Next.js):

// next.config.js
module.exports = {
  async headers() {
    return [{
      source: '/(.*)',
      headers: [
        { key: 'X-Content-Type-Options', value: 'nosniff' },
        { key: 'X-Frame-Options', value: 'SAMEORIGIN' },
        { key: 'Referrer-Policy', value: 'strict-origin-when-cross-origin' },
        { key: 'Permissions-Policy', value: 'camera=(), microphone=(), geolocation=()' },
        { key: 'Strict-Transport-Security', value: 'max-age=31536000; includeSubDomains; preload' },
      ]
    }]
  }
}

ตัวอย่างการโอนการตั้งค่า (Apache .htaccess):

Header always set X-Content-Type-Options "nosniff"
Header always set X-Frame-Options "SAMEORIGIN"
Header always set Referrer-Policy "strict-origin-when-cross-origin"
Header always set Permissions-Policy "camera=(), microphone=(), geolocation=()"
Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains; preload"

ตัวอย่างการโอนการตั้งค่า (Nginx):

add_header X-Content-Type-Options "nosniff" always;
add_header X-Frame-Options "SAMEORIGIN" always;
add_header Referrer-Policy "strict-origin-when-cross-origin" always;
add_header Permissions-Policy "camera=(), microphone=(), geolocation=()" always;
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" always;

ชัยชนะอย่างรวดเร็ว: เพิ่มหัวข้อทั้ง 5 ข้อด้านบนไปยังการตั้งค่าเซิร์ฟเวอร์ของคุณ ใช้เวลาเพียง 5 นาทีและปรับปรุงความปลอดภัยของคุณทันทีในเครื่องมือการสแกนใด ๆ

HSTS Preload

HTTP Strict Transport Security (HSTS) แจ้งให้เบราว์เซอร์ทราบว่าให้ใช้ HTTPS สำหรับโดเมนของคุณเสมอ — แม้ก่อนคำขอแรก หากไม่มี HSTS การเยี่ยมชมครั้งแรกของผู้ใช้ไปยังเว็บไซต์ของคุณอาจยังใช้ HTTP (ซึ่งเสี่ยงต่อการถูกดักจับ) ก่อนที่จะเปลี่ยนเส้นทางไปยัง HTTPS

HSTS header:

Strict-Transport-Security: max-age=31536000; includeSubDomains; preload

คำสั่งทั้งสาม:

| คำสั่ง | ความหมาย | |---------|-----------| | max-age=31536000 | จำไว้นี้เป็นเวลา 1 ปี (เป็นวินาที) | | includeSubDomains | ใช้กับทุกซับโดเมนด้วย | | preload | ขอให้รวมในรายการ preload ของเบราว์เซอร์ |

รายการ HSTS preload:

การป้องกัน HSTS ระดับสุดยอด เบราว์เซอร์จะมีรายการโดเมนที่ต้องใช้ HTTPS เสมอในตัว หากคุณส่งโดเมนของคุณไปยัง hstspreload.org หมายความว่า:

  • ผู้เยี่ยมชมครั้งแรกจะได้รับ HTTPS ทันที (ไม่ต้องมีการเปลี่ยนเส้นทางจาก HTTP → HTTPS)
  • เป็นการยากสำหรับผู้โจมตีที่จะทำการลดระดับการเชื่อมต่อ
  • เป็นการป้องกันถาวร (ยากที่จะลบเมื่อส่งแล้ว)

ข้อกำหนดสำหรับ HSTS preload:

  1. ใบรับรอง HTTPS ที่ถูกต้อง
  2. เปลี่ยนเส้นทาง HTTP ทั้งหมดไปยัง HTTPS (รวมถึงซับโดเมน)
  3. HSTS header ที่มี max-age >= 31536000
  4. HSTS header รวม includeSubDomains
  5. HSTS header รวม preload
  6. ซับโดเมนทั้งหมดต้องรองรับ HTTPS

คำเตือน: ส่งเพื่อขอให้รวมใน preload เฉพาะถ้าซับโดเมนทั้งหมดของคุณรองรับ HTTPS คำสั่ง includeSubDomains หมายความว่าซับโดเมนที่มี HTTP เท่านั้นจะไม่สามารถเข้าถึงได้

ชัยชนะอย่างรวดเร็ว: หากคุณมี HTTPS อยู่ในซับโดเมนทั้งหมดแล้ว ให้เพิ่ม HSTS header แบบเต็มและส่งไปยัง hstspreload.org การประมวลผลใช้เวลาปีก่อน แต่การป้องกันนั้นถาวร

การตรวจสอบช่องโหว่

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

การตรวจสอบช่องโหว่จะตรวจสอบอะไร:

  • ซอฟต์แวร์เก่า: WordPress, ปลั๊กอิน, ไลบรารี JavaScript ที่มี CVEs ที่ทราบ
  • ไฟล์ที่เปิดเผย: .env, .git, wp-config.php, dumps ฐานข้อมูล
  • การรั่วไหลของข้อมูล: หัวข้อเวอร์ชันเซิร์ฟเวอร์, โหมดดีบัก, สแตกเทรซ
  • ข้อมูลประจำตัวเริ่มต้น: หน้าแอดมินที่ไม่มีการตรวจสอบ, รหัสผ่านเริ่มต้น
  • พอร์ต/บริการที่เปิด: บริการที่ไม่จำเป็นเปิดเผยต่ออินเทอร์เน็ต
  • จุดฉีด: ฟอร์มที่ไม่มีการป้องกัน CSRF, การป้อนข้อมูลที่ไม่ได้รับการตรวจสอบ

ช่องโหว่ที่พบบ่อยตามแพลตฟอร์ม:

| แพลตฟอร์ม | ช่องโหว่สูงสุด | แก้ไข | |------------|----------------|--------| | WordPress | ปลั๊กอินที่เก่า | อัปเดตอัตโนมัติ + WAF | | Shopify | สิทธิ์แอพของบุคคลที่สาม | ตรวจสอบรายการแอพทุกไตรมาส | | Next.js | เส้นทาง API ที่เปิดเผย | Auth middleware + การจำกัดอัตรา | | เว็บไซต์สถิต | การกำหนดค่า CDN ไม่ถูกต้อง | ตรวจสอบกฎการแคช | | กำหนดเอง | SQL injection | คำสั่งพารามิเตอร์ |

ความถี่ในการตรวจสอบ:

  • ทุกวัน: การสแกนผิวอัตโนมัติ (SSL, หัวข้อ, ไฟล์ที่เปิดเผย)
  • รายสัปดาห์: การตรวจสอบช่องโหว่ขึ้นอยู่กับ (npm audit, เครื่องมือวิเคราะห์ปลั๊กอิน WordPress)
  • รายเดือน: การสแกนเชิงลึกพร้อมการทดสอบที่ได้รับการตรวจสอบ
  • หลังจากการปรับใช้ทุกครั้ง: การตรวจสอบความผิดพลาด

ชัยชนะอย่างรวดเร็ว: รัน npm audit (Node.js) หรือเปิดดูรายการปลั๊กอิน CMS ของคุณเพื่อหาส่วนประกอบที่ล้าสมัย แก้ไขปัญหาที่มีความรุนแรงสูง/สูงทันที

เนื้อหาผสม

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

ประเภทของเนื้อหาผสม:

| ประเภท | ความรุนแรง | ตัวอย่าง | พฤติกรรมของเบราว์เซอร์ | |--------|------------|----------|-----------------------| | กิจกรรม | สูง | สคริปต์ HTTP, iframe, CSS | ถูกบล็อกโดยค่าเริ่มต้น | | พาสซีฟ | ปานกลาง | รูปภาพ HTTP, วิดีโอ, เสียง | โหลดพร้อมข้อความเตือน |

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

การค้นหาเนื้อหาผสม:

  1. เปิด Chrome DevTools → คอนโซล
  2. มองหาข้อความเตือน "Mixed Content"
  3. หรือใช้การสแกนด้วย crawler (Screaming Frog, LANGR)

แหล่งที่มาของเนื้อหาผสมที่พบบ่อย:

  • URL http:// ที่ฝังในเนื้อหา (บทความ, คำอธิบายผลิตภัณฑ์)
  • วิดเจ็ตของบุคคลที่สามที่โหลดทรัพยากร HTTP
  • เนื้อหาที่ฝัง (การฝังจาก YouTube ที่เก่า, วิดเจ็ตโซเชียลมีเดีย)
  • CSS background-image ที่มี URL HTTP
  • ฟอนต์โหลดผ่าน HTTP

การแก้ไขเนื้อหาผสม:

<!-- ไม่ดี -->
<img src="http://example.com/image.jpg" />

<!-- ดี -->
<img src="https://example.com/image.jpg" />

<!-- ดีที่สุด (สัมพันธ์กับโปรโตคอล ปรับให้เข้ากับโปรโตคอลของหน้า) -->
<img src="//example.com/image.jpg" />

การแก้ไขในฐานข้อมูล (WordPress):

UPDATE wp_posts SET post_content = REPLACE(post_content, 'http://yourdomain.com', 'https://yourdomain.com');
UPDATE wp_postmeta SET meta_value = REPLACE(meta_value, 'http://yourdomain.com', 'https://yourdomain.com');

ชัยชนะอย่างรวดเร็ว: เปิดหน้าแรกของคุณใน Chrome กด F12 ตรวจสอบแท็บคอนโซลเพื่อหาข้อความเตือนเนื้อหาผสม แก้ไขทุกอย่างที่ปรากฏ — สิ่งเหล่านี้จะปรากฏชัดเจอสำหรับ Google

ความเสี่ยงจากสคริปต์ของบุคคลที่สาม

ทุกสคริปต์จากภายนอกที่คุณโหลดคือความเสี่ยงด้านความปลอดภัย (และประสิทธิภาพ) ที่อาจเกิดขึ้น สคริปต์ของบุคคลที่สามสามารถ:

  • ถูกทำให้เสีย (การโจมตีจากห่วงโซ่อุปทาน)
  • ติดตามผู้ใช้ของคุณโดยไม่มีความยินยอม (การละเมิด GDPR)
  • ทำให้เว็บไซต์ของคุณช้าลง (ทำให้การเรนเดอร์ติดขัด, ความล่าช้าในการเชื่อมต่อ)
  • ทำให้ฟังก์ชันผิดปกติ (การอัปเดตเวอร์ชัน, การหยุดทำงาน)
  • ฉีดเนื้อหาที่ไม่ต้องการ (สคริปต์โฆษณาที่ผิดพลาด)

ตรวจสอบสคริปต์ของบุคคลที่สามของคุณ:

| สคริปต์ | จำเป็นไหม? | ระดับความเสี่ยง | ทางเลือก | |---------|------------|----------------|----------| | Google Analytics | บ่อยใช่ | ต่ำ | การติดตามด้านเซิร์ฟเวอร์ | | วิดเจ็ตแชท | บางครั้ง | ปานกลาง | โซลูชันที่โฮสต์เอง | | ปุ่มแชร์โซเชียล | แทบไม่ | ปานกลาง | แบ่งปันลิงก์แบบสแตติก | | A/B testing | บางครั้ง | สูง | การทดสอบด้านเซิร์ฟเวอร์ | | พิกเซลรีมาร์เก็ตติ้ง | การตัดสินใจทางธุรกิจ | สูง | ข้อมูลจากบุคคลแรก | | Font CDNs | สะดวก | ต่ำ | ฟอนต์ที่โฮสต์เอง |

การบรรเทาความเสี่ยงสำหรับสคริปต์ที่สำคัญ:

  1. Subresource Integrity (SRI): การตรวจสอบ hash ป้องกันไม่ให้สคริปต์ที่ถูกดัดแปลงโหลด
<script src="https://cdn.example.com/lib.js"
        integrity="sha384-oqVuAfXRKap7fdgcCY5uykM6+R9GqQ8K/uxAE+sO0..."
        crossorigin="anonymous"></script>
  1. ข้อจำกัด CSP: อนุญาตให้สคริปต์จากโดเมนที่รู้จักเท่านั้น
  2. iframe ที่มีการแยกออก: แยกวิดเจ็ตของบุคคลที่สาม
  3. ตรวจสอบเป็นประจำ: ทบทวนทรัพยากรจากภายนอกทั้งหมดทุกไตรมาส
  4. การตรวจสอบ: แจ้งเตือนเมื่อมีโดเมนภายนอกใหม่ปรากฏในหน้าของคุณ

ชัยชนะอย่างรวดเร็ว: จัดทำรายการ