Google แสดงผลลัพธ์ออร์แกนิกที่แตกต่างกันสำหรับคำค้นหาเดียวกัน ขึ้นอยู่กับต้นทางทางภูมิศาสตร์ของคำขอ — แม้ว่าจะปิดการปรับแต่งเฉพาะบุคคลแล้วก็ตาม คำค้นหา "เมล็ดกาแฟที่ดีที่สุด" จาก IP ของดาต้าเซ็นเตอร์ในนิวยอร์ก จะให้ SERP ที่แตกต่างจากคำค้นหาเดียวกันจาก IP ที่อยู่อาศัยในเบอร์ลิน ความแตกต่างนี้ไม่ใช่แค่เรื่องรูปลักษณ์ แต่ถูกบังคับใช้โดยอัลกอริทึมการจัดอันดับตามภูมิภาคของ Google การปรับเนื้อหาให้เข้ากับท้องถิ่น และปฏิสัมพันธ์ของพารามิเตอร์ gl (ประเทศ), hl (ภาษา) และ cr (จำกัดประเทศ) การตรวจสอบ SEO ตามภูมิศาสตร์เป้าหมายโดยไม่เข้าใจกลไกเหล่านี้ รับประกันได้ว่าข้อมูลจะทำให้เข้าใจผิด บทความนี้อธิบายว่าเหตุใด SERP จึงแตกต่างกัน การหมุนพร็อกซีช่วยหลีกเลี่ยงการตรวจจับได้อย่างไร และขั้นตอนการทำงานสำหรับการติดตามอันดับในกว่า 30 ตลาด
เหตุใด SERP จึงแตกต่างกันในแต่ละภูมิภาค — ccTLD, gl, hl และการปรับแต่งเฉพาะบุคคล
Google กำหนด SERP "ท้องถิ่น" ผ่านสัญญาณหลายอย่างรวมกัน วิธีที่ง่ายที่สุดคือ TLD ของโดเมนค้นหา — google.de เทียบกับ google.co.jp แต่การใช้ ccTLD เพียงอย่างเดียวนั้นไม่เพียงพอ Google ยังอ่านพารามิเตอร์ gl เพื่อแทนที่ประเทศที่สันนิษฐานไว้ ตัวอย่างเช่น google.com?gl=DE บังคับให้แสดงผลลัพธ์ภาษาเยอรมันแม้จะอยู่บนโดเมนสากล พารามิเตอร์ hl กำหนดภาษาของอินเทอร์เฟซ ซึ่งมีผลต่อภาษาของผลลัพธ์ แต่ไม่ส่งผลต่อการให้น้ำหนักตามภูมิศาสตร์ คำขอที่มี hl=en&gl=JP จะส่งคืนผลลัพธ์ภาษาญี่ปุ่นเป็นภาษาอังกฤษ — ซึ่งเป็นสาเหตุของความสับสนที่พบบ่อย
นอกเหนือจากพารามิเตอร์ Google ยังใช้การระบุตำแหน่งทางภูมิศาสตร์ตาม IP หากคุณส่งคำขอจาก IP ของสหรัฐฯ ไปยัง google.de Google อาจยังคงแสดงผลลัพธ์ผสมระหว่างภาษาอังกฤษและภาษาเยอรมัน เนื่องจากตรวจพบต้นทางของ IP นี่คือปัญหาหลักสำหรับการตรวจสอบ SEO: ที่อยู่ IP รั่วไหลตำแหน่งของผู้ใช้ การปิดการปรับแต่งเฉพาะบุคคลผ่าน pws=0 จะลบประวัติผู้ใช้ แต่ไม่ได้ปิดการอนุมานตำแหน่ง วิธีเดียวที่เชื่อถือได้ในการจำลองผู้ใช้ในพื้นที่คือการกำหนดเส้นทางการรับส่งข้อมูลผ่าน IP ที่เป็นของตลาดเป้าหมาย — ควรเป็น IP ที่อยู่อาศัย
IP ที่อยู่อาศัยเทียบกับ IP ดาต้าเซ็นเตอร์ — การตรวจจับและการหลีกเลี่ยง Captcha
Google จัดประเภทช่วง IP อย่างจริงจัง IP ดาต้าเซ็นเตอร์ — AWS, GCP, DigitalOcean — ถูกตราหน้าว่าไม่ใช่มนุษย์ภายในไม่กี่วินาที การทดสอบภายในของเราแสดงอัตราความล้มเหลว 60–80% สำหรับ IP ดาต้าเซ็นเตอร์เมื่อสอบถาม Google ด้วยพารามิเตอร์ gl คำขอจำนวนมากส่งคืน captcha หรือ SERP ที่ถูกตัดทอน ในทางกลับกัน IP ที่อยู่อาศัยจะกลมกลืนไปกับการรับส่งข้อมูลปกติ แต่พูลพร็อกซีที่อยู่อาศัยก็มีปัญหาของตัวเอง: ความหน่วงสูง, แบนด์วิธจำกัด และความแม่นยำของตำแหน่งทางภูมิศาสตร์ที่แปรผัน IP "ที่อยู่อาศัย" จากผู้ให้บริการพร็อกซีอาจเป็น NAT ของผู้ให้บริการมือถือที่ Google จับคู่ไปยังภูมิภาคอื่น
การหลีกเลี่ยง Captcha ไม่ใช่เรื่องของการ "ซ่อน" — แต่เป็นการเลียนแบบเบราว์เซอร์จริง ส่ง User-Agent ที่ถูกต้อง, Accept-Language ที่ตรงกับ hl และ Cookie jar ใหม่ต่อเซสชัน การตรวจจับบอทของ Google ยังดูที่จังหวะเวลาของคำขอ การส่ง 100 คำขอใน 2 วินาทีจาก IP เดียวกันจะกระตุ้นให้เกิด captcha ให้ลดความถี่เหลือ 1–2 คำขอต่อนาทีต่อ IP ใช้พูลอย่างน้อย 50 IP ต่อตลาดเพื่อรักษาปริมาณงาน การแลกเปลี่ยนคือ: ความหน่วงและต้นทุนที่สูงขึ้น เทียบกับอัตรา captcha ที่ต่ำลง เรายอมรับอัตรา captcha 5–10% เป็นเรื่องปกติ และลองใหม่ด้วย IP อื่น
ขั้นตอนการทำงานสำหรับการติดตามอันดับในกว่า 30 ประเทศ
รูปแบบการทำงานนั้นตรงไปตรงมา: หนึ่ง IP ต่อตลาด, หนึ่งเซสชันใหม่ต่อคำค้นหา อย่าใช้คุกกี้ซ้ำข้ามตลาด ตัวอย่าง shell ด้านล่างแสดงการสอบถามแบบ curl ขั้นต่ำสำหรับ SERP ภาษาเยอรมันโดยใช้พร็อกซีที่อยู่อาศัย:
#!/bin/bash
# Query Google for "SEO tools" with German gl and English hl, via a residential proxy
PROXY="http://user:pass@residential-proxy-pool:8080"
curl -s --proxy "$PROXY" \
-H "User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36" \
-H "Accept-Language: en-US,en;q=0.9,de;q=0.8" \
-H "Cookie: NID=...; CONSENT=..." \
"https://www.google.com/search?q=SEO+tools&gl=DE&hl=en&pws=0&num=10" \
| grep -oP '(?<=&url=)[^&]+' | head -10คำสั่งนี้ดึง URL ออร์แกนิก 10 อันดับแรก สำหรับระบบที่ใช้งานจริง ให้แทนที่พร็อกซีแบบคงที่ด้วยจุดสิ้นสุดแบบหมุนที่ส่งคืน IP ใหม่ต่อคำขอ เครื่องมือเช่น proxy-chain หรือสคริปต์ Python แบบกำหนดเองที่ใช้ requests พร้อมเซสชันต่อ IP ทำงานได้ดี จัดเก็บรายการพร็อกซีของแต่ละตลาดในไฟล์แยกต่างหาก และหมุนเวียนตามลำดับ
สำหรับ 30+ ประเทศ คุณต้องมีพูลพร็อกซี 30+ พูล — แต่ละพูลต้องมีอย่างน้อย 20–50 IP เพื่อหลีกเลี่ยงการจำกัดอัตรา พูลเดียวของ IP ทั่วโลกไม่เพียงพอ เนื่องจากการระบุตำแหน่งทางภูมิศาสตร์ของ Google จะนำทางผิด เราใช้ไฟล์กำหนดค่าที่จับคู่รหัสประเทศกับจุดสิ้นสุดพร็อกซี:
{
"DE": "http://user:pass@de-residential.zone:8080",
"JP": "http://user:pass@jp-residential.zone:8080",
"BR": "http://user:pass@br-residential.zone:8080"
}แต่ละคำค้นหาตลาดจะทำงานในเธรดหรืองาน async แยกกัน โดยมีช่วงพัก 60 วินาทีต่อ IP ทุกๆ 10 คำขอ จังหวะนี้ทำให้อัตรา captcha ต่ำกว่า 3% ในตลาดส่วนใหญ่ ส่วนที่ยากไม่ใช่โค้ด — แต่คือการหาแหล่งพร็อกซีที่อยู่อาศัยที่เชื่อถือได้พร้อมตำแหน่งทางภูมิศาสตร์ที่ได้รับการยืนยัน ผู้ให้บริการหลายรายอ้างว่า "DE" แต่กำหนดเส้นทางผ่านดาต้าเซ็นเตอร์ในแฟรงก์เฟิร์ต ตรวจสอบโดยดู ASN ของ IP และเปรียบเทียบกับการอนุมานตำแหน่งของ Google (เช่น ใช้ส่วนหัว X-Robots-Tag หรือผลลัพธ์ท้องถิ่นที่รู้จัก)
การแลกเปลี่ยน: ความสดใหม่เทียบกับต้นทุน
การรัน 30 ตลาดทุกชั่วโมงด้วยพร็อกซีที่อยู่อาศัยมีค่าใช้จ่ายประมาณ $200–$500 ต่อเดือนเฉพาะค่าพร็อกซี ขึ้นอยู่กับผู้ให้บริการและปริมาณข้อมูล คุณสามารถลดต้นทุนได้โดยใช้ IP ดาต้าเซ็นเตอร์สำหรับตลาดที่ Google เข้มงวดน้อยกว่า — โดยทั่วไปคือประเทศเล็กๆ แต่ข้อมูลจะมีสัญญาณรบกวนมากขึ้น ทางเลือกอื่นคือยอมรับรอบการรีเฟรช 24 ชั่วโมง และประมวลผลคำขอเป็นชุดในเวลากลางคืน ซึ่งอัตรา captcha จะลดลง ไม่มีอาหารกลางวันฟรี หากคุณต้องการติดตามอันดับรายวันใน 30 ประเทศ ให้จัดงบประมาณสำหรับพร็อกซีที่อยู่อาศัยและกลไกการลองใหม่ที่แข็งแกร่ง สิ่งใดที่น้อยกว่านี้จะให้ผลลัพธ์ที่ดูแม่นยำแต่ผิดโดยพื้นฐาน — และนั่นแย่กว่าการไม่มีข้อมูลเลย