Google menyampaikan hasil organik yang berbeza untuk pertanyaan yang sama bergantung pada asal geografi permintaan — walaupun peribadatan dilumpuhkan. Pertanyaan untuk “best coffee beans” dari IP pusat data di New York mengembalikan SERP yang berbeza daripada pertanyaan yang sama dari IP kediaman di Berlin. Perbezaan ini bukan sekadar kosmetik. Ia dikuatkuasakan oleh algoritma kedudukan serantau Google, penyetempatan kandungan, dan interaksi parameter gl (negara), hl (bahasa), dan cr (had negara). Menjalankan pemantauan SEO yang disasarkan secara geografi tanpa memahami mekanisme ini menjamin data yang mengelirukan. Artikel ini menerangkan mengapa SERP berbeza, bagaimana putaran proksi mengurangkan pengesanan, dan aliran kerja operasi untuk menjejak kedudukan merentasi 30+ pasaran.
Mengapa SERP Berbeza Merentasi Rantau — ccTLD, gl, hl, dan Peribadatan
Google menentukan SERP “setempat” melalui gabungan isyarat. Yang paling mudah ialah TLD domain carian — google.de vs google.co.jp. Tetapi menggunakan ccTLD sahaja tidak mencukupi. Google juga membaca parameter gl untuk mengatasi negara yang diandaikan. Contohnya, google.com?gl=DE memaksa hasil Jerman walaupun pada domain global. Parameter hl menetapkan bahasa antara muka, yang mempengaruhi bahasa hasil tetapi bukan pemberat geografi. Permintaan dengan hl=en&gl=JP mengembalikan hasil Jepun dalam bahasa Inggeris — satu punca kekeliruan yang biasa.
Di luar parameter, Google menggunakan geolokasi berasaskan IP. Jika anda menghantar permintaan dari IP AS ke google.de, Google mungkin masih menyajikan campuran hasil Inggeris dan Jerman kerana ia mengesan asal IP. Ini adalah masalah utama untuk pemantauan SEO: alamat IP membocorkan lokasi pengguna. Melumpuhkan peribadatan melalui pws=0 mengeluarkan sejarah pengguna, tetapi ia tidak melumpuhkan inferens lokasi. Satu-satunya cara yang boleh dipercayai untuk mensimulasikan pengguna tempatan adalah dengan menghalakan trafik melalui IP yang dimiliki oleh pasaran sasaran — idealnya IP kediaman.
IP Kediaman vs IP Pusat Data — Pengesanan dan Pengelakan Captcha
Google secara aktif mengklasifikasikan julat IP. IP pusat data — AWS, GCP, DigitalOcean — ditandakan sebagai bukan manusia dalam beberapa saat. Ujian dalaman kami menunjukkan kadar kegagalan 60–80% untuk IP pusat data apabila membuat pertanyaan Google dengan parameter gl; banyak permintaan mengembalikan captcha atau SERP yang dikurangkan. IP kediaman, sebaliknya, bercampur dengan trafik biasa. Tetapi kumpulan proksi kediaman mempunyai masalah tersendiri: latensi tinggi, lebar jalur terhad, dan ketepatan geolokasi yang berubah-ubah. IP “kediaman” daripada pembekal proksi mungkin sebenarnya adalah NAT pembawa mudah alih yang dipetakan Google ke rantau yang berbeza.
Pengelakan captcha bukan tentang “menyembunyikan” — ia tentang meniru pelayar sebenar. Hantar User-Agent yang betul, Accept-Language yang sepadan dengan hl, dan balang Cookie yang segar untuk setiap sesi. Pengesanan bot Google juga melihat pada masa permintaan. Letusan 100 pertanyaan dalam 2 saat dari IP yang sama mencetuskan captcha. Hadkan kepada 1–2 permintaan seminit setiap IP. Gunakan kumpulan sekurang-kurangnya 50 IP setiap pasaran untuk mengekalkan kadar pemprosesan. Pertukarannya: latensi dan kos yang lebih tinggi berbanding kadar captcha yang lebih rendah. Kami menerima kadar captcha 5–10% sebagai normal dan cuba semula dengan IP yang berbeza.
Aliran Kerja untuk Penjejakan Kedudukan Merentasi 30+ Negara
Corak operasi adalah mudah: satu IP setiap pasaran, satu sesi segar setiap pertanyaan. Jangan guna semula kuki merentasi pasaran. Coretan shell berikut menunjukkan siasatan minimum berasaskan curl untuk SERP Jerman menggunakan proksi kediaman:
#!/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 -10Ini mengambil 10 URL organik teratas. Untuk sistem pengeluaran, gantikan proksi statik dengan titik akhir berputar yang mengembalikan IP segar setiap permintaan. Alat seperti proxy-chain atau skrip Python tersuai menggunakan requests dengan sesi setiap IP berfungsi dengan baik. Simpan senarai proksi setiap pasaran dalam fail berasingan dan putarkannya secara kitaran.
Untuk 30+ negara, anda memerlukan 30+ kumpulan proksi — setiap kumpulan mesti mengandungi sekurang-kurangnya 20–50 IP untuk mengelakkan had kadar. Satu kumpulan IP global tidak mencukupi kerana geolokasi Google akan salah hala. Kami menggunakan fail konfigurasi yang memetakan kod negara ke titik akhir proksi:
{
"DE": "http://user:pass@de-residential.zone:8080",
"JP": "http://user:pass@jp-residential.zone:8080",
"BR": "http://user:pass@br-residential.zone:8080"
}Setiap pertanyaan pasaran berjalan dalam benang berasingan atau tugas tak segerak, dengan tempoh rehat 60 saat setiap IP selepas setiap 10 permintaan. Kekerapan ini mengekalkan kadar captcha di bawah 3% di kebanyakan pasaran. Bahagian yang sukar bukanlah kod — ia adalah mendapatkan proksi kediaman yang boleh dipercayai dengan geolokasi yang disahkan. Banyak pembekal mendakwa “DE” tetapi laluan melalui pusat data Frankfurt. Sahkan dengan memeriksa ASN IP dan bandingkan dengan inferens lokasi Google (contohnya, menggunakan pengepala X-Robots-Tag atau hasil tempatan yang diketahui).
Pertukaran: Kesegaran vs. Kos
Menjalankan 30 pasaran setiap jam dengan proksi kediaman berharga kira-kira $200–$500 sebulan dalam yuran proksi sahaja, bergantung pada pembekal dan jumlah data. Anda boleh mengurangkan kos dengan menggunakan IP pusat data untuk pasaran di mana Google kurang agresif — biasanya negara yang lebih kecil. Tetapi data akan menjadi lebih bising. Alternatifnya adalah menerima kitaran muat semula 24 jam dan kelompokkan pertanyaan pada waktu malam, apabila kadar captcha menurun. Tiada makan tengah hari percuma. Jika anda memerlukan penjejakan kedudukan harian merentasi 30 negara, peruntukkan belanjawan untuk proksi kediaman dan mekanisme cuba semula yang kukuh. Kurang daripada itu menghasilkan data yang kelihatan tepat tetapi pada asasnya salah — dan itu lebih buruk daripada tiada data langsung.