การตรวจสอบคีย์เวิร์ด

ปัญหา "200 OK แต่มีข้อผิดพลาด"

เครื่องมือ uptime ทุกตัวสามารถบอกได้ว่าระบบเซิร์ฟเวอร์ตอบกลับด้วยรหัส HTTP 2xx หรือไม่ สัญญาณนี้ดูเหมือนจะน่าเชื่อถือ แต่ความจริงแล้วอาจหลอกคุณได้บ่อยกว่าที่คิด หน้าแรกอาจแสดงหน้าเปล่าสีขาวและยังคงตอบกลับ 200 ได้ หน้าในตะกร้าสินค้าอาจหายไปปุ่ม "ซื้อทันที" แบบเงียบๆ หลัง deployment โดยไม่เคยแสดงข้อผิดพลาด WordPress อาจแสดงข้อความ "เกิดข้อผิดพลาดในการเชื่อมต่อฐานข้อมูล" – แน่นอนว่าแสดงผลเป็น 200 OK พร้อม HTML จริง

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

ควรมอนิเตอร์สตริงแบบไหน

คำสำคัญที่ดีคือข้อความที่ยืนยันได้ว่าบริเวณสำคัญของเว็บเพจทำงานถูกต้อง ตัวอย่าง:

• หน้าแรกของร้านค้าออนไลน์: มอนิเตอร์ "เพิ่มสินค้าลงตะกร้า" หรือชื่อสินค้ายอดนิยม หากแคตตาล็อกเสีย ข้อความนี้จะหายไป – คุณก็จะรู้ทันที
• หน้าล็อกอิน: มอนิเตอร์ "เข้าสู่ระบบ" หรือ "กู้คืนรหัสผ่าน" หากเกิดข้อผิดพลาด JS ฟอร์มจะหายไปพร้อมกับคำเหล่านี้
• บล็อกหรือพอร์ทัล: มอนิเตอร์ชื่อบทความล่าสุด ถ้า CMS แสดงเนื้อหาวันเก่า ข้อความจะไม่ตรงกัน
• หน้าราคาสินค้า: มอนิเตอร์สตริงของราคา เมื่อ deploy ทำให้บล็อกราคาเสีย จะเห็นปัญหาทันที
• endpoint สถานะ / health: มอนิเตอร์ "ok" หรือ "healthy" หาก upstream ล่ม endpoint อาจตอบกลับ "degraded" – ข้อความนี้จะไม่ตรง

ยังสามารถใช้โหมด ไม่ควรมี – แจ้งเตือนเมื่อมีข้อความที่ไม่ควรปรากฏ นิยมใช้กับ: "Database connection error", "Whoops! Something went wrong", "โหมดบำรุงรักษา", "Fatal error", "เร็วๆ นี้" หากข้อความเหล่านี้แสดงใน production คุณจะได้รับแจ้งทันที

การตรวจสอบทำงานอย่างไร

มอนิเตอร์จะส่งคำขอ HTTP(S) GET (หรือวิธีอื่นเช่น POST, PUT ฯลฯ) ตามสุด 5 redirect ดึง response body แล้วค้นหาคำสำคัญโดยไม่สนใจตัวพิมพ์เล็กใหญ่ ผลลัพธ์การจับคู่จะถูกบันทึกพร้อมรหัส HTTP เวลาตอบสนอง และ SSL หากเงื่อนไขไม่ถูกต้อง 2 ครั้งติดกัน (ค่าตั้งต้น) จะเปิดเหตุการณ์และแจ้งเตือนผ่านช่องทางต่างๆ ที่ตั้งค่าไว้ – Email, Telegram, Slack, Discord และ SMS

สำหรับเนื้อหาที่เปลี่ยนแบบ dynamic (SPA) ที่ข้อความจะปรากฏหลังจาก JavaScript ทำงาน ให้ใช้ฟีเจอร์ premium multi-location ที่ใช้เบราว์เซอร์ headless จริงผ่าน ScrapingBee

เชื่อมกับ HTTP และ SSL

มอนิเตอร์คำสำคัญหนึ่งตัวใน DiagnoSEO Uptime Monitoring จะตรวจสอบหน้าเว็บอย่างครบถ้วนทั้งรหัส HTTP, เวลาตอบสนอง, SSL, การหมดอายุโดเมน, DNS record และตรวจจับผู้ให้บริการโฮสติ้ง มอนิเตอร์เดียวป้องกันคุณจากทุกปัญหา – เซิร์ฟเวอร์ล่ม, ใบรับรองหมดอายุ, DNS ถูกเปลี่ยน และ ข้อผิดพลาดเนื้อหาเงียบ

วิธีตั้งค่า

เปิดเครื่องมือ คลิก "เพิ่มมอนิเตอร์" เลือกประเภท "คำสำคัญ" วาง URL ระบุข้อความ เลือก "ต้องมีข้อความนี้" หรือ "ต้องไม่มีข้อความนี้" ตั้งช่วงเวลา (1-30 นาทีตามแพ็คเกจ) แล้วบันทึก จากรอบตรวจสอบถัดไป มอนิเตอร์จะดูแลหน้านั้นและแจ้งเตือนทันทีเมื่อข้อความหาย – แม้ทุกสัญญาณอื่นจะดูปกติ

คำถามที่พบบ่อย

• Keyword monitoring คืออะไร?

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

• ฉันใช้ HTML ได้หรือแค่ plain text?

  ได้ทั้งคู่ การค้นหาทำแบบ substring บน raw response body คุณสามารถระบุ plain text ("เพิ่มสินค้าลงตะกร้า") ส่วนของ HTML (<button class="buy">) หรือแอตทริบิวต์เจาะจงใดๆ ทุกสิ่งที่ปรากฏในโค้ดต้นฉบับ HTML สามารถใช้ตรวจสอบได้

• ต่างจากเครื่องมือ content-diff ตรงไหน?

  เครื่องมือ diff จะเปรียบเทียบกับ baseline และรายงานทุกความเปลี่ยนแปลง การมอนิเตอร์คำสำคัญจะกำหนดเจาะจงว่าต้องมีหรือห้ามมีอะไรบนหน้า Diff มักแจ้งเตือนเยอะเกินไปในเว็บเพจแบบไดนามิก ส่วน keyword monitoring เน้นจุดสำคัญเท่านั้น

• ฉันตรวจสอบได้ไหมว่าข้อความผิดพลาดห้ามอยู่บนหน้า?

  ได้ – ใช้โหมด "ต้องไม่มี" กับ keyword อย่าง "Internal Server Error" หรือ "เกิดข้อผิดพลาด" มอนิเตอร์จะล้มเหลวถ้ามีผิดพลาดโผล่มา เหมาะกับจับ error 500 ที่ตอบ HTTP 200 พร้อมหน้า error (ปัญหาตั้งค่าบ่อยของหลาย framework)

• Keyword monitoring ใช้งานกับเว็บไซต์ที่แสดงผลด้วย JavaScript ได้ไหม?

  โดยปกติไม่ – มอนิเตอร์จะดึง HTML ดิบก่อนที่ JS จะทำงาน ถ้าเป็น SPA หรือเว็บ heavy-JS ข้อความต้องปรากฏใน HTML ตอบกลับรอบแรก (เช่น server-rendered หรือใน <noscript>) การตรวจสอบที่เรนเดอร์โดยเบราว์เซอร์เป็นฟีเจอร์เสริมต่างหาก