วิธีรับมือกับลิงก์ /goto ของ Google ในไปป์ไลน์ SERP

สรุปใน 30 วินาที

เมื่อวันที่ 26 สิงหาคม 2026 Google ยืนยันว่าลิงก์ผลการค้นหาจะผ่าน google.com/goto?url=[โทเคนที่เข้ารหัส] ก่อนถึงปลายทาง Barry Schwartz รายงานใน Search Engine Roundtable และ Search Engine Land และโฆษกของ Google ยืนยันว่านี่เป็นส่วนหนึ่งของ"มาตรการทางเทคนิคระยะยาวเพื่อรับมือกับรูปแบบการละเมิดที่พัฒนาไปอย่างต่อเนื่อง"

ถ้าทีมของคุณสกัด URL ปลายทางจากผลการค้นหาของ Google (การติดตามอันดับ การสคราป SERP การเก็บข้อมูลสำหรับ AI) ก็มีสมมติฐานหนึ่งที่เพิ่งแตกไป: URL จริงไม่ปรากฏในลิงก์อีกต่อไป มันถูกเข้ารหัสเป็นโทเคนที่เบราว์เซอร์ตามต่อแบบ redirect ปกติ

ข่าวดีคือแก้ได้ และตัวแก้เล็กกว่าที่คนส่วนใหญ่คิด เราไม่ถอดรหัสโทเคนได้ แต่แก้มันได้ด้วยคำขอ HTTP พิเศษหนึ่งครั้ง และมันเป็นเชิงกำหนด จึงแคชได้ บทความนี้พาคุณเดินผ่านการแก้แบบ 30 นาที: ตรวจจับการเปลี่ยนแปลง แก้โทเคนอย่างปลอดภัย และยืนยันว่ารายงานยังแสดงหน้าที่ถูกต้องอยู่ ถ้าคุณไม่ได้สคราป SERP และไม่ได้เทียบอันดับกับ URL ที่เก็บมาจากหน้าเหล่านั้น ข้ามไปที่ "สิ่งที่การเปลี่ยนแปลงไม่กระทบ" ได้เลย ไม่มีอะไรเปลี่ยนบนเว็บไซต์ของคุณ

สิ่งที่เปลี่ยนไปจริงๆ

หลายปีมาแล้ว ลิงก์ผลการค้นหาของ Google ฝากปลายทางจริงไว้ในตัวลิงก์เอง:

<a href="https://yoursite.com/landing-page?utm_...">...

ตอนนี้ผลลัพธ์เดียวกันอาจเป็นลิงก์พาสทรู:

<a href="https://www.google.com/goto?url=TtFp1Lc2026...*">...

เมื่อตามไป Google จะตอบกลับเป็น HTTP redirect ไปยังปลายทาง มีสองจุดสำคัญเกี่ยวกับการทำงานของมัน:

• โทเคนถูกเข้ารหัสและปลอมแปลงไม่ได้ จากการ reverse engineering อิสระ (เผยแพร่สิงหาคม 2026) มันประกอบด้วย marker 1 ไบต์ ตัวระบุคีย์ 4 ไบต์ และข้อมูลในรูปแบบ Tink เปลี่ยนไปหนึ่งอักขระ Google ตอบกลับเป็น HTTP 400 คุณปลอมโทเคนหรือถอดรหัส URL โดยไม่มีคีย์ของ Google ไม่ได้
• โทเคนเป็นเชิงกำหนด URL ปลายทางเดียวกันให้โทเคนเดียวกันเสมอ จุดเดียวนี้ทำให้การแก้ทั้งหมดถูก: แก้โทเคนครั้งเดียวแล้วแคชไว้ได้เลย

Derek Perkins จาก Nozzle สังเกตการเปิดตัวเกือบ"100%"ข้ามผู้ให้บริการ IP ประเภทเรสซิเดนเชียลหลายราย และนี่คือเหตุผลที่ครั้งนี้ไม่ใช่แค่การทดลอง

สิ่งที่ยังคงอยู่หลังการเปลี่ยนแปลง

ที่พารามิเตอร์ ved ยังอยู่เป็นเรื่องน่าสังเกต: ข้อมูลอันดับและประเภทการคลิกที่เครื่องมือติดตามอันดับเคยอ่านจากลิงก์ผลลัพธ์ยังอยู่ มีเพียง URL ปลายทางที่ถูกซ่อน

สิ่งที่การเปลี่ยนแปลงไม่กระทบ

• อันดับและทราฟฟิก ระบบจัดอันดับของ Google ไม่เกี่ยวข้องกับลิงก์ที่เรนเดอร์ออกมา
• ข้อมูล Google Search Console อันดับ การแสดงผล และคลิกใน GSC มาจากข้อมูลภายในของ Google และไม่ได้รับผลกระทบ
• ครอเลอร์ที่มาที่เว็บไซต์ของคุณ Googlebot, GPTBot และบอตใดๆ ที่ครอวล์ หน้าเว็บของคุณ ไม่แตะ google.com/goto มันปรากฏเฉพาะในลิงก์ที่ Google เรนเดอร์ให้คุณดู
• Bing และเครื่องมือค้นหาอื่น นี่เป็นการเปลี่ยนแปลงจากฝั่ง Google เท่านั้น

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

ตรวจสอบว่าคุณได้รับผลกระทบหรือไม่

รันการตรวจสี่ข้อ สองข้อแรกใช้เวลาห้านาที อีกสองข้อที่เหลือเป็นการคุยกับผู้ให้บริการ

ถ้าทุกข้อสะอาด ไม่ต้องทำอะไร: เพิ่มหน้านี้เป็น bookmark แล้วไปต่อ

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

ขั้นตอนที่ 1: ตรวจจับโทเคนในจุดที่ปรากฏ

สิ่งที่ต้องทำ. ในสคริปต์สกัด SERP ของคุณ เก็บลิงก์ผลลัพธ์ทั้งหมดแล้วติดธงรายการที่ขึ้นต้นด้วย https://www.google.com/goto?url= (จับคู่ทั้ง /goto?url= แบบโปร่งเปล่าที่ปรากฏบนบางอินเทอร์เฟซ และ url= ที่ตามด้วย payload ลักษณะ base64 ด้วย) บันทึกอัตราการติดธงต่อคำค้น — นั่นคือตัวบ่งชี้การเปิดตัวของคุณ และจากข้อสังเกตของ Derek Perkins: การเปิดตัวไม่เท่ากันตามช่วง IP ดังนั้นติดตามตามผู้ให้บริการ ไม่ใช่ภาพรวม

ผลลัพธ์ที่คาดหวัง. ค่า goto_rate ต่อคำค้น 0% หมายถึงแหล่งข้อมูลยังคืนลิงก์ตรงอยู่ 100% หมายถึง tokenize เต็มตัว

การตรวจสอบคุณภาพ. รันคำค้นเดียวกันจากสอง IP ต่างกัน ถ้าฝั่งหนึ่ง tokenize แล้วอีกฝั่งไม่ แสดงว่าเกิดการแยกช่วง IP และต้องจัดการทั้งสองฝั่ง

วิธีกู้คืน. ถ้าตัวอย่างไม่มีผลลัพธ์ที่ผิดเลยแต่คุณสงสัยว่าถูก tokenize ตรวจดูว่าสคริปต์สกัดของคุณอ่าน DOM ที่เรนเดอร์ด้วย JavaScript แทน HTML ดิบหรือไม่ โทเคนอาจปรากฏในมาร์กอัปที่เรนเดอร์แล้วแม้การตอบสนองดิบจะยังอยู่ในรูปแบบเดิม

ขั้นตอนที่ 2: แก้โทเคนด้วย redirect เดียว

สิ่งที่ต้องทำ. เมื่อผลลัพธ์มีโทเคน ตามลิงก์จากฝั่งเซิร์ฟเวอร์โดยปิดการตาม redirect แล้วอ่าน header Location:

curl -sI "https://www.google.com/goto?url=TtFp1Lc..." | grep -i location

การตอบสนองคือ HTTP 3xx ไปยังปลายทางจริง เก็บไว้ กฎสองข้อทำให้ขั้นตอนนี้ถูกและปลอดภัย:

• แคชตามโทเคน ไม่ใช่ตาม URL เพราะการ tokenize เป็นเชิงกำหนด แก้โทเคนหนึ่งครั้งต่อหนึ่งโทเคนก็พอ เก็บ token -> resolved_url แล้วใช้ซ้ำตลอด
• อย่าคราวล์ `google.com/goto` ราวกับเป็นหน้าเพจเด็ดขาด Google เพิ่ม Disallow: /goto? ลงใน robots.txt ของตัวเองปลายกรกฎาคม 2026 URL นี้ตั้งใจชัดเจนว่าไม่ให้ครอเลอร์ดึงมา ตัวดึงที่ทำงานถูกต้องจะตามลิงก์โทเคนแบบเบาๆ แล้วอ่านแค่ chain ของ redirect ตัวดึงที่ผิดพลาดจะเก็บหรือ index URL goto เองและทำข้อมูลของคุณพัง ถึงปลายกรกฎาคม มี URL แบบนี้ถูก index ไปเกือบ 3,750 URL บน google.com เองแล้ว

เช็คต้นทุนก่อนปล่อย: การสแกน SERP แรกที่มีผลลัพธ์หลายร้อยรายการ หมายถึงคำขอเพิ่มอีกหลายร้อยไปที่ google.com ซึ่งเป็นโหลดประเภทที่ตัวตรวจจับบอตของ Google จับตาพอดี แคชเชิงกำหนดลดสิ่งนี้เหลือหนึ่งคำขอต่อโทเคนเฉพาะ ดังนั้นอย่าข้ามขั้นนี้

ผลลัพธ์ที่คาดหวัง. ตารางจับคู่ที่มั่นคงระหว่างโทเคนกับปลายทาง สุ่มโทเคนมาสิบตัวตรวจด้วยเบราว์เซอร์: แต่ละตัวควรไปถึงหน้าที่สมเหตุสมผล

การตรวจสอบคุณภาพ. ยืนยันว่าความยาวโทเคนคงที่ข้าม URL ต่างๆ และ URL ปลายทางเดียวกันให้โทเคนเหมือนกันเสมอ ถ้าเริ่มไม่ตรงกัน แสดงว่าเกิดการหมุนคีย์ (ดูขั้นตอนที่ 5)

วิธีกู้คืน. โทเคนที่ตอบ 400 หมายถึงปลอม ถูกตัด หรือมาจากเซสชันหมดอายุ เก็บ SERP ใหม่แล้วลองอีกครั้ง ล้มเหลวสองครั้งติดต่อกันมักแปลว่า HTML ที่เก็บไว้นานแล้ว ไม่ใช่โทเคนเสีย

ขั้นตอนที่ 3: เก็บ URL ปลายทาง ไม่ใช่ลิงก์พาสทรู

สิ่งที่ต้องทำ. ส่วนที่เหลือของไปป์ไลน์ (การจับคู่คีย์เวิร์ดกับหน้า การตรวจดัชนี การตรวจ schema) ต้องเห็น URL ปลายทาง ดังนั้นหลังขั้นตอนที่ 2 ให้เก็บสามฟิลด์ต่อผลลัพธ์: resolved_url, token, accessed_at ถอดลิงก์ goto ออกจากคอลัมน์ URL ในรายงานใดๆ; URL google.com ในรายงานคีย์เวิร์ดคือความผิดพลาดด้านคุณภาพข้อมูลหลากหลายรูปแบบ

ถ้าเพิ่มตัวแก้โทเคนอาทิตย์นี้ไม่ได้ ขั้นกลางที่ปลอดภัยคือเว้นปลายทางไว้เปล่าแทนการเก็บโทเคน: ข้อมูลอันดับกับตำแหน่งยังมีความหมาย มีแค่คอลัมน์ URL ที่ว่าง เครื่องมือที่บอกชัดๆ ว่า"ไม่มี URL" อ่านง่ายกว่าเครื่องมือที่รายงานสตริงโทเคนเป็น URL จริงมาก

ผลลัพธ์ที่คาดหวัง. รายงานที่ 100% ของแถวเป็น URL http(s) ของโดเมนตนเอง และแถว google.com เป็นศูนย์

การตรวจสอบคุณภาพ. เทียบข้อมูลระดับ URL กับ Search Console สำหรับสิบคีย์เวิร์ด แถวควรตรงกัน ถ้า Search Console ให้อันดับกับ URL ที่รายงานคุณบอกว่า"ไม่พบ" แสดงว่าตัวแก้โทเคนหรือตัวแยกมีรูรั่ว

วิธีกู้คืน. ถ้า URL ส่วนน้อยยังแก้ไม่ได้ ให้บันทึกโทเคนเหล่านั้นแยกต่างหาก ความล้มเหลวส่วนใหญ่ย้อนกลับไปหาสองสาเหตุในขั้นตอนที่ 2: HTML เก่า หรือกำแพงตรวจจับบอตบนคำขอถัดไป

ขั้นตอนที่ 4: ตรวจสอบว่าผู้ให้บริการทำอะไรอยู่

สิ่งที่ต้องทำ. ถ้าคุณพึ่งเครื่องมือติดตามอันดับหรือ SERP API (รวมถึงพวกที่ built บนข้อมูล Google ที่ถูกสคราปมา) การเปิดตัวดำเนินมาเป็นสัปดาห์แล้ว ถามห้าข้อนี้ แล้วใช้เทียบกับการเปลี่ยนแปลงใดๆ ในรายงาน:

ผลลัพธ์ที่คาดหวัง. ได้การแก้ที่ยืนยันแล้ว หรือได้เหตุผลชัดเจนที่จะย้าย ภายใน 30 วัน คุณควรผสาน URL จากรายงานกับบันทึกการเปลี่ยนแปลงเว็บไซต์ได้โดยไม่มีเสียงรบกวน

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

ขั้นตอนที่ 5: จับตาขั้นตอนถัดไป

กลไกนี้ไม่หยุดนิ่ง ติดตามสามอย่างทุกเดือน:

1. การหมุนคีย์ ตัวอย่าง reverse engineering เจอตัวระบุคีย์สี่ตัวหมุนเวียน โดยหนึ่งตัวครองกว่า ("ee47aa4d" ประมาณ 62% ของโทเคน) ถ้าคีย์ที่ห้าโผล่และสัดส่วนที่ครองเริ่มขยับ ให้เตรียมรับการล้างแคช: แก้โทเคนใหม่เมื่อมีการหมุน
2. การกระจายไปอินเทอร์เฟซอื่น เจอ /goto ในลิงก์โฆษณาและผลลัพธ์ประเภทอื่นด้วย ถ้าเครื่องมือของคุณแตะโฆษณาหรือรูปภาพ ให้ขยายการค้นหาในขั้นตอนที่ 1
3. การเข้มงวดต่อเนื่อง สิ่งนี้อยู่ในลำดับที่ยาวกว่า: บังคับเรนเดอร์ JavaScript (ต้นปี 2025), การเปิดตัว SearchGuard, การปิด &num=100 (กันยายน 2025), และคดี DMCA Section 1201 ต่อ SerpApi (ธันวาคม 2025) แต่ละรายการมีเอกสารแยกกัน และบทความ reverse engineering รวบรวมส่วนใหญ่ไว้ด้วยกัน คาดหวังว่า URL ปลายทางจะยากขึ้นเรื่อยๆ ไม่ใช่ง่ายลง

ตรวจสอบผลลัพธ์ขั้นสุดท้าย

• [ ] ตัวตรวจจับขั้นตอนที่ 1 ทำงานใน CI หรือตามกำหนด และบันทึก goto_rate ต่อคำค้น
• [ ] โทเคนที่สุ่มมาทั้งหมดถูกแก้เป็นปลายทางจริงและสุ่มตรวจด้วยเบราว์เซอร์แล้ว
• [ ] ไม่มี URL google.com/goto ในรายงานของคุณ (หาในไฟล์ export ล่าสุด)
• [ ] URL ของสิบคีย์เวิร์ดตรงกับ Search Console ทีละแถว
• [ ] ผู้ให้บริการยืนยันกลยุทธ์การแก้แล้ว หรือข้อมูลอันดับย้ายไปใช้ GSC API แล้ว
• [ ] มีการตรวจการหมุนคีย์โดยเฉพาะในจังหวะประจำเดือนของคุณ

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

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

ถอดรหัสโทเคน goto ได้ไหม จากภายนอกไม่ได้ มันเป็น payload เข้ารหัสรูปแบบ Tink และเปลี่ยนหนึ่งอักขระจะได้ HTTP 400 ดังนั้นปลอมก็ไม่ได้ ทางที่เป็นไปได้คือตาม redirect แล้วอ่าน header Location — ซึ่งก็คือสิ่งที่เบราว์เซอร์ทำอยู่แล้ว

ตามลิงก์ `/goto` ด้วยสคริปต์สคราปได้ไหม ในทางปฏิบัติ การตามลิงก์โทเคนผ่าน redirect คือสิ่งที่การคลิกจากเบราว์เซอร์ทำ แต่ Google บล็อก /goto? ใน robots.txt ของตัวเอง และข้อกำหนดจำกัดการเข้าถึงผลการค้นหาโดยอัตโนมัติ ถ้าคุณสคราป SERP คุณอยู่ผิดฝั่งของข้อกำหนดอยู่แล้ว การเปิดตัวครั้งนี้ไม่ได้เปลี่ยนเรื่องนั้น แค่ทำให้มันหนักขึ้น เลือกจุดยืนด้านคอมพลายแอนซ์ก่อนสร้างตัวแก้โทเคน

มีอะไรที่ต้องเปลี่ยนแปลงบนเว็บไซต์ฉันไหม ไม่ การเปลี่ยนแปลงทั้งหมดอยู่ในลิงก์ที่ Google เรนเดอร์ สิ่งที่ต้องตรวจคือทุกเครื่องมือที่อ่าน SERP แทนคุณ — นั่นคือขั้นตอนที่ 4

ผู้เขียน: Olivia Stone นักวิจัย SERP Intelligence ประจำ Auspia (วิเคราะห์มากกว่า 25,000 คำค้น) เขียนเกี่ยวกับการวิเคราะห์ SERP รูปแบบอันดับ และวิธีที่การเปลี่ยนแปลงของผลการค้นหาส่งผลต่อข้อมูลอันดับ