SEO เชิงเทคนิค
เครื่องมือตรวจสอบ HTTP Link Header สำหรับ SEO
ป้อน URL แล้วเราจะดึงข้อมูลจากฝั่งเซิร์ฟเวอร์และแยกวิเคราะห์ HTTP Link response header เพื่อหา rel="canonical", rel="alternate" hreflang และรายการ rel="next"/"prev" ตามมาตรฐาน RFC 8288 — จากนั้นเปรียบเทียบกับแท็ก HTML <link> บนหน้าเดียวกันและแจ้งเตือนหากพบความขัดแย้ง
ป้องกันด้วย reCAPTCHA เราดึงข้อมูล URL จากฝั่งเซิร์ฟเวอร์ (ป้องกัน SSRF) และอ่าน response header ของมัน — ไม่มีการจัดเก็บข้อมูลใด ๆ
เหตุใด Link header จึงสำคัญ
เครื่องมือตรวจสอบ canonical และ hreflang เกือบทั้งหมดจะดูเฉพาะแท็ก HTML <link> ใน <head> ของหน้าเว็บ RFC 8288 กำหนดตำแหน่งที่สองที่ใช้ได้เท่าเทียมกันสำหรับประกาศสัญญาณเดียวกันนี้ นั่นคือ HTTP response header Link: Google ระบุและรองรับกลไกนี้อย่างชัดเจน WordPress และ CDN หลายเจ้าส่งมันโดยอัตโนมัติ และนี่คือวิธีเดียวที่จะกำหนด canonical หรือ hreflang ให้กับทรัพยากรที่ไม่ใช่ HTML — ไฟล์ PDF รูปภาพ หรือการตอบกลับ JSON API — เพราะสิ่งเหล่านี้ไม่มี <head> ให้ใส่แท็ก <link> เนื่องจากไม่มีที่ใดแสดงผลมันให้เห็น header ที่ถูกตั้งโดยกฎ edge ของ CDN ซึ่งขัดแย้งกับแท็ก HTML อย่างเงียบ ๆ หรือไฟล์ PDF ที่ไม่มีใครเคยนึกถึงการตั้ง canonical แบบนี้ จึงมองไม่เห็นทั้งในเบราว์เซอร์และในเครื่องมือใด ๆ ที่อ่านแค่ HTML
สิ่งที่เครื่องมือนี้ตรวจสอบ
ตัวแยกวิเคราะห์ RFC 8288 ของจริง — ไม่ใช่การเดาด้วย regex — ที่อ่าน response header จริงที่เซิร์ฟเวอร์ของคุณส่งมา
การแยกวิเคราะห์ Link header ตาม RFC 8288
แยกวิเคราะห์ค่า header Link: ดิบ — รวมถึงหลายรายการที่คั่นด้วยจุลภาค พารามิเตอร์ในเครื่องหมายคำพูด และรายการ rel หลายค่า — ให้เป็นรายการ rel=canonical, rel=alternate และ rel=next/prev ที่มีโครงสร้าง พร้อมแจ้งเตือนส่วนที่แยกวิเคราะห์เป็น link-value ที่ถูกต้องไม่ได้
ตรวจความขัดแย้ง canonical ระหว่าง header กับ HTML
เปรียบเทียบเป้าหมาย rel="canonical" ใน header กับแท็ก HTML <link rel="canonical"> ของหน้าเว็บ ความไม่ตรงกันเป็นปัญหาจริงที่มองไม่เห็น: เสิร์ชเอนจินอาจเลือกใช้สัญญาณใดสัญญาณหนึ่ง ทำให้ canonicalization ไม่แน่นอน นอกจากนี้ยังแจ้งเตือน canonical ใน header ที่มีมากกว่าหนึ่งรายการ เป้าหมายข้ามโดเมน และการอ้างอิงตัวเอง (self-reference) ของ URL ที่ดึงมา
Hreflang ผ่าน header
ตรวจสอบรหัสภาษาของทุกรายการ header rel="alternate"; hreflang="..." ตรวจว่าขาด x-default หรือไม่เมื่อมีตั้งแต่ 2 รายการขึ้นไป ตรวจว่าขาดรายการอ้างอิงตัวเองหรือไม่ และตรวจรหัสซ้ำที่ชี้ไป URL ต่างกัน — จากนั้นเปรียบเทียบทั้งชุดกับแท็ก hreflang ของ HTML บนหน้าเว็บเพื่อหาความขัดแย้ง
การครอบคลุมทรัพยากรที่ไม่ใช่ HTML
สำหรับไฟล์ PDF รูปภาพ หรือการตอบกลับ API (ไม่มี HTML จึงไม่มีทางมีแท็ก <link> ได้เลย) จะแจ้งเตือนกรณีที่ไม่มีการส่ง canonical ผ่าน header — หมายความว่าทรัพยากรนั้นไม่มีสัญญาณ canonicalization สำหรับเสิร์ชเอนจินเลย ซึ่งเป็นสิ่งที่มองข้ามได้ง่ายมาก
คำถามที่พบบ่อย
HTTP Link header คืออะไร และเว็บไซต์ของฉันจะส่งมันไปทำไม
มันคือ response header ที่กำหนดโดย RFC 8288 ซึ่งบรรจุความสัมพันธ์แบบ rel เดียวกัน (canonical, alternate, next, prev และอื่น ๆ) ที่ปกติเขียนเป็นแท็ก HTML <link> — ต่างกันตรงที่มันใช้ได้กับการตอบกลับทุกประเภท ไม่ว่าจะเป็น HTML หรือไม่ก็ตาม WordPress หลักส่ง Link header บางส่วนโดยอัตโนมัติ CDN และ reverse proxy จำนวนมากสามารถแทรกหรือเขียนทับมันที่ edge ได้ บางครั้งโดยที่เว็บไซต์ต้นทางไม่รู้ตัว
canonical ใน header ไม่ตรงกับแท็ก canonical ใน HTML ของฉัน นี่คือบั๊กหรือไม่
เกือบตลอดเวลา ใช่ เอกสารของ Google เองระบุว่าทั้งสองเป็นสัญญาณที่ใช้ได้ แต่ไม่รับประกันว่าอันไหนจะชนะเมื่อขัดแย้งกัน — ในทางปฏิบัติสิ่งนี้ทำให้ canonicalization ของ URL นั้นคาดเดาไม่ได้ ตรวจสอบว่ามี CDN, ชั้น cache หรือปลั๊กอินใดกำลังแทรก header โดยแยกจากเทมเพลต HTML ของคุณหรือไม่ แล้วทำให้ทั้งสองตรงกัน
ฉันสามารถใช้ hreflang โดยไม่มีแท็ก HTML <link> เลยได้หรือไม่
ได้ — รูปแบบ header เทียบเท่ากับแท็กอย่างสมบูรณ์ และเป็นวิธีมาตรฐานในการติดแท็ก hreflang ให้ทรัพยากรที่ไม่ใช่ HTML (เช่น PDF) หรือเพิ่ม hreflang ให้การตอบกลับโดยไม่ต้องแตะเทมเพลต HTML กฎเดียวกันยังใช้ได้: ทุกเวอร์ชันภาษาควรระบุตัวเอง (self-reference) และแนะนำให้มี x-default เมื่อมีตั้งแต่สองเวอร์ชันขึ้นไป
Google ใช้ Link response header จริงหรือไม่
ใช่ เอกสาร Google Search Central ระบุอย่างชัดเจนว่า HTTP header เป็นวิธีที่รองรับสำหรับการกำหนดทั้ง rel="canonical" และ rel="alternate" hreflang โดยระบุเป็นพิเศษว่าไฟล์ที่ไม่ใช่ HTML คือเหตุผลที่กลไกนี้มีอยู่
URL หรือเนื้อหาของฉันถูกจัดเก็บไว้ที่ไหนหรือไม่
ไม่ การดึงข้อมูลเกิดขึ้นที่ฝั่งเซิร์ฟเวอร์เฉพาะสำหรับการตรวจสอบครั้งนี้เท่านั้น และผลลัพธ์จะถูกส่งกลับไปยังเบราว์เซอร์ของคุณโดยตรง ไม่มีการเขียนลงฐานข้อมูลหรือบันทึกใด ๆ นอกจากตัวนับ rate-limit